In Section 7.0, Transaction Control At The SQL Level, at http://www.sqlite.org/lockingv3.html, it says:
"If the SQL COMMIT command turns autocommit on and the autocommit logic then tries to commit change but fails because some other process is holding a SHARED lock, then autocommit is turned back off automatically. This allows the user to retry the COMMIT at a later time after the SHARED lock has had an opportunity to clear." Also in section 3.0 it says: "Only one EXCLUSIVE lock is allowed on the file and no other locks of any kind are allowed to coexist with an EXCLUSIVE lock." So, if process A has an EXCLUSIVE lock for writing and process B attempts a COMMIT, process B immediately receives an SQLITE_BUSY error, and has to start over again. There is no queue then. Does this create a problem where process B never gets to write because process A (C, D, etc.) are continually getting in ahead of B? B Can't get a PENDING lock to keep it's position in line. It seems that there should be a queue of Pending locks so processes can keep their place in line? So this could be implemented as a COMMIT and there would be a specified timeout as a PRAGMA command? If the timeout was set to 0 (default), then there would be no queue and it would be backwards compatible. Of course, the Pending queue would work against all other lock conditions currently in effect on the database, not just EXCLUSIVE's. Good idea, bad idea, false alarm? Scott The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
