This is a request for a small change to the handling of multiple connections. I think it would significantly enhance the usefulness there via allowing multiple "views" of the data.
Consider that I have two simultaneous connections to one file, named Con1 and Con2. They could be in one process or one thread -- that's irrelevant. Either one may write to the DB; we don't know yet. For starters, assume that their journal mode is MEMORY. Both connections begin with "begin transaction". Already I'm dead in the water; one of those will fail presently with "database is locked". But it doesn't need to be that way! Each connection can have its own journal file, especially if it's in memory. Once one connection commits, the other connection will no longer be allowed to commit. It will be forced to rollback (or perhaps rebase if there are no conflicts). Multiple WAL files could be supported in a similar fashion; they just need some kind of unique naming scheme. For recovery, the user would be prompted to select one or none. It doesn't seem that far from Sqlite's current behavior. Thoughts? ~Brannon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
