[EMAIL PROTECTED] wrote:
Mikey C <[EMAIL PROTECTED]> wrote:
Please implement table and row level locking. :-)
People commonly believe that doing so must be easy. I
certainly get a lot of requests for it from people who
think they know how. But in fact, row-level locking
is extraordinarily difficult. To my knowledge, nobody
has yet come up with a way to do it unless you:
* Add a server process to coordinate access.
* Accept that the database might be corrupted if
an application crashes while writing.
* Make writing to the database very, very slow.
* Double the size of the database file.
If you think you know a way to implement row-level
locking that does not impose one of the above
limitations, then please tell me and I will look
into the matter.
I'm not an expert but let me propose such solution:
Multi- Generational Architecture like Interbase/Firebird can cope with
all except the last point (double size of database file) - however in
the last case periodical vaccum could shrink database.
There is also no need to have server process - each instance of sqlite
library could be a server.
Shared lock manager could be required or simply each instance of sqlite
library could have separate one.
Shared lock manager is tricky idea (maybe it could be for example dumb
manager in each sqlite library with shared memory pool and if one
instance terminate another one could detect it and play that role?)
In fact that is as I fairy know how it's implemented in Firebird Classic
Server (where each server process has separate lock manager I suppose)
This classic server processes are spawn by xinetd deamon.
I see sqlite in very similar manner : sqlite library is attached to each
spawned process which uses it.
Regards
Boguslaw Brandys
