On Sun, 23 Nov 2014 14:34:23 -0500 (EST) Joseph Fernandes <josfe...@redhat.com> wrote:
> Ok I get it now. Yes we are using a single db connection object, But > few questions, > 1) how would making sqlite3 single thread that improve the > performance? Is there a special advantage in this mode than the > multithread one? The locking code isn't compiled and sqlite3 don't spend time checking them. The code in single thread compiled with multithread is minimal, but it's there wasting time. > 2) Will it not block (wait or give a SQLITE_BUSY) the multiple thread > of the app (in our case glusterfs IO threads) as now they have to > wait for the single thread to complete the task? Sqlite3 can manage only one writer (INSERT/UPDATE/DELETE) and multiple readers, the whole db is lock when a writer writes. Don't matter if sqlite3 is in multithread mode or not. You must implement in your sqlite3 thread owner, the control logic between writing threads. Your threads send data to sqlite3 thread and it decides, with your rules, which ones and in what order apply to db. When I did it, I found particular cases in my data management logic that make it faster, f.ex. batch writes sended by some threads to update the same row multiple times, so only the last one was applied or apply them in one transaction, which is faster than apply them one by one. > ~Joe --- --- Eduardo Morras <emorr...@yahoo.es> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
