[Qt-interest] Qsqlite performance with multiple processes ?

Scott Aron Bloom Scott.Bloom at sabgroup.com
Wed Apr 1 18:38:57 CEST 2009


What platform (s)?

 

Does the DB access truly have to be multi threaded?  Or can you access the db thread via signals and slots allowing all the data to be accessed via 1 thread?

 

I have successfully used SQLite in a multithreaded world, but note, all the data and record locking that you get for free with MySQL (or any multi-user, multi-access database) you wind up doing it yourself.

 

Making the SQLite thread locking, didn’t solve the issue that you still cant have multiple live queries going…

 

Scott

 

 

 

From: qt-interest-bounces at trolltech.com [mailto:qt-interest-bounces at trolltech.com] On Behalf Of Stephen Collyer
Sent: Wednesday, April 01, 2009 6:17 AM
To: Bill KING
Cc: qt-interest at trolltech.com
Subject: Re: [Qt-interest] Qsqlite performance with multiple processes ?

 

I was trying to see if I could feasibly replace a dependency on Mysql
by using sqlite. I suspect for my needs I could get away with it (very
few writes) but it would take me too long to rewrite the DB access
layer at the moment, so I won't be doing it anyway.

2009/3/31 Bill KING <bill.king at trolltech.com>

Also, if you're looking at performance/locking from a multi-process
situation, sqlite's not really the right tool for the job. A more full
featured db engine would be recommended then. There are some
zero-administration dbs out there, firebird's a good example.


Stephen Collyer wrote:
> I've taken a look at the Sqlite driver code in
> sql/drivers/sqlite2/qsql_sqlite2.cpp
> and I see the following code:
>
> 195     // keep trying while busy, wish I could implement this better.
> 196     while ((res = sqlite_step(currentMachine, &colNum, &fvals,
> &cnames)) == SQLITE_BUSY) {
> 197         // sleep instead requesting result again immidiately.
> 198 #if defined Q_WS_WIN32
> 199         Sleep(1000);
> 200 #else
> 201         sleep(1);
> 202 #endif
>
> This seems to imply that if a sqlite DB is locked for write by another
> process,
> then this code would block the calling process for 1 second before a
> retry.
> This would seem to make the sqlite driver unusable for any real
> multiprocess
> applications.
>
> So:
>
> 1) is my conclusion correct, or am I confused ?
> 2) why has such a huge retry interval been chosen ?
> 3) does anyone have real experience with qslite in a multiprocess app ?
>
> --
>
> Stephen Collyer

> ------------------------------------------------------------------------
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>


--
Bill King, Software Engineer
Qt Software, Nokia Pty Ltd
Brisbane Office




-- 
--

Stephen Collyer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090401/188b3341/attachment.html 


More information about the Qt-interest-old mailing list