Hi John,
Thank you for letting us know. I will check it out and let you know if I
encounter any problems.
By the way, you are right, your branch is called 'dbBackEnd'. The full URI of
the branch is lp:~mira-dev/mira/dbBackEnd. I think running 'bzr info' from your
local branch would be quite revealing. You can also find a list of Mira's code
branches here: https://code.launchpad.net/mira
Regards,
Max
On 22 May 2011, at 16:16, John Deal wrote:
> Hello All,
>
> I just pushed to the dbBackEnd branch (I think that is what it is called) an
> update of the SQLite DB functionality. Here is the scoop.
>
> It is multi-threaded with multiple readers or one writer enforced with
> OS-level locks. I have verified it does successfully allow multiple readers
> at a time and writes work. This is using multiple DB connections where each
> thread has a dedicated DB connection.
>
> I also have a series of test functions in main.cpp that drive the DbDirectory
> class. This was the fastest way to test the threading issue. This does not
> test the rest of the server. I know these functions do not belong in
> main.cpp but where should we keep test functions?
>
> I spent significant time with the members of the SQLite email list. One
> knowledgeable member states my multi-threaded code should work without the OS
> locks. However, without them I will get "database locked" errors in my
> tests. I could retry the writes that get the "database locked" error but
> that complicates the code a bit and does present the remote possibility of a
> writer lockout. I feel using OS locks to allow multiple readers or one
> writer is a better general solution.
>
> You can share a DB connect across threads (this is a fairly new SQLite
> feature) but this serializes the requests basically making DB access
> single-threaded.
>
> Most likely the biggest risk to this code is what I call a "hanging select".
> It seems when a select is executed, it puts a read-only lock on the DB. This
> lock remains until the the associated prepared statement is reset. This lock
> only seems to affect other DB connections so if a write is attempted from
> another DB connection with a hanging select the write will get a "database
> locked" error. This means that without making writes exclusive, there is
> race condition between when a select is executed and when it can be reset.
> This means that selects (actually all SQL statements) must always reset even
> if an error is returned. I think I have covered all of the cases.
>
> Anyway if anyone can give the dbBackEnd branch (how do I find out the name of
> this?) a try and let me know what you find that would be great.
>
> Thanks,
>
> John
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Mira-development mailing list
> Mira-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mira-development
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Mira-development mailing list
Mira-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mira-development
