[yunqa.de] Re: sqlite3_busy_timeout() with TDISQLite3Database?
- From: "email@xxxxxxxxxx" <email@xxxxxxxxxx>
- To: yunqa@xxxxxxxxxxxxx
- Date: Fri, 09 Dec 2011 15:51:09 +0100
Thank you Ralf...
I still have a problem though, let me explain my situation before asking
the question:
You see my application is split into a GUI app and an "engine"
executable, both sharing the same db.
The engine does index directories & files and put the info in a database
(write to the db), the GUI just display these files & folders (read, no
db writing).
I've chosen to move the engine code into a separate EXE to keep the GUI
app responsive, the DB component I was using until now allowed
record-level locking, so there was no problem reading and writing to the
DB at the same time (provided it's not the same record, plus I use
critical section, in both the GUI and engine EXEs, whenever possible)
But the DB wasn't acid and I had issues when/if the # of files indexed
was too large (ie. if I indexed a 500GB disk full of data!), which is
not the case of DISQLite, thus the switch "attempt" that I'm doing right
now.
I tried using this code:
sqlite3_busy_timeout(MyDatabase.Handle, 1000);
It eliminated the "Database is locked" error, but now the GUI app isn't
as responsive as it was.
I *really* like how the GUI app respond, it's crazy fast, but since the
Engine EXE will be writing almost all the time on the db (not just the
initial index/scan, but also update indexed data with new info), the GUI
app will be greatly affected, which means that the speed advantage will
be lost.
I use critical section whenever possible (in both the GUI and engine
EXEs), but ideally the GUI app should be as fast as possible, which is
not possible given this whole DB locking.
So, my question is: is it possible to make record-level (or at least
table-level) locking instead of DB-level locking and busy timeout. I
tried lowering the timeout interval but it didn't give the result I'm
after (plus, target PCs can be slower than mine, so the timeout may not
be reliable for client machines)
Thanks!
Nora.
_______________________________________________
Delphi Inspiration mailing list
yunqa@xxxxxxxxxxxxx
//www.freelists.org/list/yunqa
Other related posts:
