Looking for the best multithreading patterns for database access

abforce

I've got a database class that is moved to a background thread by moveToThread. And then sets up a connection to the database server. Since QSqlDatabase should be used in the thread which set it up, so other parts of program should send their requests to this object and wait for response.

For example my database class has a slot called getUserById which takes an ID and queries the database and emits getUserByIdCompleted. Generally talking, my class has lots of foo slots and fooCompleted signals.

I could think of two problems with this method:

If two entities simultaneously emit signal to getUserById how they could distinguish their own response, when database entity emits getUserByIdCompleted?
AFAIK this way, every classes wanting to access database should declare lots of signals only intended to be connected to the database class? Am I right? For example if class Foo wants to query a user, it should have a signal called something like heyDatabaseGetUserById and then we should connect it to database's getUserById slot. I think that's bad practice to have every classes defined with such signals. Is it possible to send signal to the database class without caller class's such signals?

SGaist

Hi and welcome to devnet,

Are you looking for something like QxOrm ?

abforce

@SGaist No. I'm not looking for ORMs. My database logic is already implemented. I'm looking for a multithread access pattern.

SGaist

Something that is not clear from your description is the multithreaded part. It seems that you only have one thread currently.

What exactly would be multi-threaded ? Also, a database is usually something synchronous so do you really need all these signals ?

JonB

Why are you moving database to background thread if you're wanting to access it all over the main thread? Is it that you send off queries and carry on and later pick up results? Or...?

abforce

@SGaist I currently have two threads: GUI thread and background thread. Database class is moved to background thread since database operations are I/O blocking.

My problem is being unable to find a mechanism to send requests from GUI thread and receive responses when operations complete.

abforce

@JNBarchan Since my program is using a QML UI layer, the GUI thread should be kept highly responsive as it may be required to deliver smooth animations. That's why I've moved database operations to a background thread.

For this purpose can I employ a callback pattern? Doing the operation in background and when it's done call the callback in GHI thread.

JonB

@abforce
You originally wrote:

so other parts of program should send their requests to this object and wait for response

If your main thread "waits for the response", then it's not very asynchronous?

I am a newcomer to Qt. I had expected, say, QSqlQuery, to offer a "begin query" function and a signal when data arrived back to read, which would have been my first thought for implementing asynchronous database calls, instead of calling synchronous functions from a background thread given that is problematic, but I don't see such a facility....?

Given which, I'll leave it to experts to help you further....

jsulm

@abforce said in Looking for the best multithreading patterns for database access:

For this purpose can I employ a callback pattern?

You can simply use signals/slots across threads