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
