Why not use optimistic locking (timestamp based pseudo locking)? It's ussually sufficient.
Olaf ----- Original Message ----- From: "Nikki Locke" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Wednesday, July 05, 2006 1:05 PM Subject: Re: [sqlite] Multiple Users > > In order to this, the next question ;-) Is a physcial Locking to the > > DB allways necessary, if more the one User (writer) connect to a DB > > and a Table? That means, is it insufficient, if I handle only a > > logical Locking in the Application instead of physcial Locking? > > As I understand it (mostly from reading this list, and a few side trips to the > documentation), the way SQLite works during a database update is that the > entire database file is locked, and remains locked until the update is > complete. If you use transactions, the entire database file is locked for the > entire transaction (*). > > Now, if there are multiple processes trying to update the same database file, > only one can update it at a given moment. Attempts to do updates, or start a > transaction (*) will fail with an error indicating the database is locked. > This applies even if the two processes are updating different tables. > > Provided you code handles the errors (by retrying the update until it > succeeds), it should work fine. However, if there are lots of processes doing > large updates to the same database file, they may be waiting for each other a > lot. > > Contrast this with a full database server (like SQL server, MySql, etc.), > which has much finer grained locking, and can let two processes update > different tables, or even different rows on the same table, at the same time. > > (*) Well, depending on the type of the transaction, it may not be locked when > you BEGIN the transaction, it may wait until the first attempt to update the > database. > > -- > Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming > http://www.trumphurst.com/ > > >
