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. 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. > _______________________________________________ > 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
