Thanks Olaf. Deeply Appreciated! Will do these tests and revert back ASAP.
Thanks & Regards, Sachin -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Olaf Schmidt Sent: Thursday, January 06, 2011 7:16 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Using WAL? "Sachin Gupta" <scgu...@ipolicynetworks.com> schrieb im Newsbeitrag news:51b335651c9a0c4ea520d47f23a580b414f5d4d...@sinnodmbx001.techmahindra.com... > Thank you for the detailed response. > It sure does help us a lot. > > One more Q for you: > Considering the requirement that we have, if we relax > the requirement of creating a in memory db, can we > instead use the SQLite in WAL mode or Shared Cache > simply for the reason that it provides concurrent access > to read/write processes? > Would it be advisable to use it in our scenario? >From what you wrote (not a very high insertion-rate, and with Read-Requests not all that often, and only for temporary caching-purposes) I don't think SQLites WAL-mode would offer you much over "singlethreaded InMemory-Mode". But just do your tests. Open an InMemory-Connection, insert your max. 1Mio Test-Records there (thereby encoding your TimeStamp-Field in a way, that it does make use of SQLites "Default-index aka RowID"). This should not take more than about 5-15seconds. Then use a high-precision timer, to test how long it takes, to: Insert one single additional Record and delete the one with the smallest "RowID-Timestamp-value" - (I would expect, that this will take only 1msec max). After testing the write-direction, you should also test (and tune) your typical read-queries against this 1Mio-records cache - and if these run under 10-15msec you should be fine with the InMemory- approach. Then, after all these tests were satisfying, you could start implementing the roughly layed-out scheme from my previous post (and I do not yet see the need, to have multiple ReaderThreads, in case you only plan to use them within the same "GUI-Application- *process*")... Multiple "GUI-reader-threads" (one per "ViewBox") *could* make sense, in case you have multiple CPU-cores available and plan to use the retrieved values from your "read-queries" for "faster visual-preparation using expensive drawing-commands" against e.g. "independent cairo-image- surfaces per thread". But if this is not the case (if you don't have multiple CPU-cores, and if your drawing-commands are relative "non-expensive-ones", then hosting your different "GUI-views" in only one Thread (the main-thread of your App-Process) would be sufficient too IMO. Olaf _______________________________________________ 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
