> Since the server is one process there is no need for Sqlite to use its > sync capability derived for multiple processes and you can KISS by > wrapping Sqlite in your own synhronization.
yes, or by using an exclusive transaction as a lock, as I've just learned. ;) > > The nice feature of a threaded application server using embedded Sqlite > is that there is no interprocess communication. We use YES! That's why I found it so sexy to use sqlite as the database. Anyway, seems to do the job quite good. Thanks for the reply Marcus > sendfile/TransmitFile for the network traffic and keep a pool of active > threads so honoring a database access is fast and efficient, especially > if the database is kept open and you save prepared statements. > JS > > Marcus Grimm wrote: >> John, >> >> thanks for the reply. >> >> you mean you do the synchronization by your selve rather >> than let it do sqlite internally ? >> >> Marcus >> >> John Stanton wrote: >> >>>We have been using such a server embadding Sqlite for some time with >>>success. We actually use pthreads exclusive and read only mutexes for >>>synchronization since all Sqlite access is threaded in the one process. >>>JS >>> > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
