Simon Slavin wrote: > >> I definitely don't agree here as we're talking about these additional >> locks existing _only_ in memory, not on disk. > > Which requires client/server architecture. Which SQLite3 doesn't > have. Once you require concurrent access features in your DBMS (i.e. > multi-user, lots of locking) the things you nned to implement start to > be easier with a client/server architecture, whether it's a standalone > client application that must be launched manually or just a unix-style > daemon running in the background which is launched automatically when > needed and quits when nothing has used it in a while.
Uhh, no it doesn't. Unless your definition of client/server is completely different than mine in the context of what we're talking about here. In this context, the 'client and server' would share the same address space (they're the same process!), hence there is no client/server separation. It would mean the exact same amount of process separation as SQLite currently employs. It would just have additional code to optimize for concurrent writes by multiple threads just as sqlite3_enable_shared_cache() does for reads: http://sqlite.org/c3ref/enable_shared_cache.html http://sqlite.org/sharedcache.html What I'm suggesting would be an extension of that shared cache, but for managing access for writes. We're just talking finer-grained locks here ... we're not talking some elaborate scheme which requires IPC and client/server communication. It doesn't need to spawn off any other daemon process here, that would be just plain stupid to do within the context of what I'm talking about. I'm just wondering if you're confused on the difference between a thread and a process .... One of these days I just need to write a patch to do this and see if it gets accepted. Unfortunately, my spare time these days is around zilch. -Brad _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
