@Howard I had tested your code earlier but it didnt seem to be stable and getting it to run was a task. Also I learnt that it is a "in-memory" database.
@Aris are you saying BDB is better and faster than SQLite ? On Sun, Nov 3, 2013 at 8:28 PM, Howard Chu <h...@symas.com> wrote: > Aris Setyawan wrote: > >> 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? >> > > Because read optimization is what was important to us when I created LMDB. > That's like asking why a hammer isn't a screwdriver. > > > 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