> SQLightning replaces the SQLite backend with Symas' LMDB, which also uses > MVCC > and thus supports high concurrency. It is also many times faster than > BerkeleyDB and vanilla SQLite.
Your MVCC is different compared to InnoDB or BDB locking. Every one should carefully read each DB's doc, then test it before decide to use it. LMDB is storage engine optimized for read. Why you don't optimize it's write using cache oblivious data structure, for example LSM tree or create new, like in sophia (sphia.org) key value DB? On 11/3/13, Howard Chu <h...@symas.com> wrote: > Aris Setyawan wrote: >> SQLite do not use row level locking, but db level locking, so it was >> the right behavior the second thread was blocked. >> >> For innodb like in SQLite, Oracle have SQLite compatible API, but use >> BDB backend. >> Since BDB use MVCC (row/page level locking), your threads only blocked >> if they will write in the same row/page. >> >> www.oracle.com/technetwork/database/berkeleydb/bdb-sqlite-comparison-wp-176431.pdf >> >> * You must aware that BDB now have AGPL license. > > SQLightning replaces the SQLite backend with Symas' LMDB, which also uses > MVCC > and thus supports high concurrency. It is also many times faster than > BerkeleyDB and vanilla SQLite. > > https://gitorious.org/mdb/sqlightning/ > >> >> On 11/3/13, Raheel Gupta <raheel...@gmail.com> wrote: >>> Hi, >>> >>> I have been using SQLite for one project of mine and I will be storing >>> TBs >>> of Data. >>> Now there will be a lot of selections in this database and I have come >>> across one problem with SQLite. >>> In journal_mode=delete the selection is database locked. >>> When one thread does a "TRANSACTION" on the database and soon after >>> another >>> thread does "SELECT" on the database (using the same connection) or vice >>> versa, the second thread has to wait till the first thread finishes. >>> >>> In order to avoid this, I had to use journal_mode=wal so that two >>> threads >>> dont have to wait when they both are doing SELECTs which might be taking >>> 3-5 seconds to process. >>> >>> I was wondering if Row Level Locking would be introduced in >>> journal_mode=delete as its there in InnoDB for MySQL. Atleast for >>> selects >>> or inserts Row Level rocking should be possible as neither modify the >>> existing rows. >>> >>> journal_mode=wal is a little slower and has its own limitations over >>> NFS. >>> >>> OR if there is a mode equivalent to innodb in SQLITE please do let me >>> know. >>> I need to do a lot of selects and inserts in my application and hence a >>> row >>> level locking is suitable vs table or database level locking. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
