On 2014/06/13 17:38, Sohail Somani wrote:
Thanks for your response. I had been trying to avoid the "writing little bits" over time to avoid an inconsistent state in the
case of a crash or user exit, but the inconsistency is not that big of a deal as the data integrity is still there and eventually,
it becomes consistent. So this solution is not the end of the world.
I actually don't have a problem with readers or writers waiting, but the problem that I am having is something holds on to the
read lock well beyond where it should. I cannot figure out who (I suspect it's a third-party framework) and what I'd like to do is
figure out what piece of code is refusing to relinquish the lock regardless of the eventual strategy I take. Even if I ended up
doing everything in the same thread, with piecemeal updates, this means that there is still something, somewhere doing the wrong
thing and I think that will probably end up biting me in an unwelcome place.
So rather than actually solve the problem, I'm looking to find the source of
the problem. Does that make sense?
For what it's worth, I did rewire the code to do everything in one thread, with piecemeal writes and it works fine, but is not a
good solution as far as I am concerned because it is just papering over the actual problem.
Apologies, did not get this from your original post, and you are right, piecemeal is not the best way, and it seems is not necessary
if you do actually find the culprit that holds the read-lock way past necessary. As for finding the culprit, are there any apps
other than your own that uses the Database? (You seem to suggest there might be if I am interpreting it correctly).
If there are, then simply stop them and test the system, start them one by one until the error happens. You did not mention the
operating system so I cannot suggest much there other to say that some OSes might add external locks on a file, such as when the
file is in a protected area in Windows UAC, or in a root area and you are not a superuser or administrator and one of the threads
reading/writing is not "cleared" by the UAC or whatever other system marshal, or maybe a virus scanner is trying to assess the file
after it changes, making sure no naughty stuff were injected - some of them hold the read lock a while because they slowly chew
through the file to avoid hogging system resources - very clever, but a pain to wait for.
If none of these finds you a culprit, it means your program is the only thing left to blame. Here we need to start with logging
every time you create a connection and start a query or creating a prepared statement. Log the handles or object IDs you get back
from any call too. Compare these to the logs when you reset or close the statements and when you free the statements and the DB
connection. Go through these with a fine-tooth comb, make sure every resource made is linked to a release in the correct order.
If it still eludes you, try to use Valgrind or something you are familiar with - make sure the compiler errors are strict or
complete or throwing exceptions on all errors (or whatever that sort of thing is called in your development platform).
One thing is certain - It isn't magic, there is a real reason for the lock and
it must be something traceable.
"Bad Programmers add corrective code. Good programmers remove defective code."
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
