>> Fine for me. It seems to be everybody else that wants their favorite >> feature imbedded in the core :-) >> >> Fine grained locking would be a great "asset" I feel. Notice I did >> not >> request a "feature." > > > On my to-do list is to write a paper that explains why fine-grain > locking is not practical without either (1) a dedicated server process > to manage the locks or (2) enhancements to OS locking primitives that > are not currently available on any OS that I am aware of. There is a > widely held belief that since OSes provide byte-level locking of files > it should be a simple matter to provide row-level locking in a > serverless database engine. The proposed paper will explain why that > belief is incorrect.
It could probably benefit a large number of integrations to have finer grained locking even if it could not be implemented for all integration types. I could see the implementation of a per-process lock (full DB lock), but with finer-grained row-level locking on a per-thread basis within the same application. Probably enabled through the use of sqlite3_enable_shared_cache(). This would actually be of great benefit to our use of SQLite which is strictly from a single multi-threaded process, no other application or process would touch the database simultaneously, just multiple threads from a single process would interact through multiple 'connections'. -Brad _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
