No TLS is used in SQLite. So you can open connection in one thread and use it in another. It's just a general suggestion to have one connection per thread. Otherwise you'll need to have some synchronization code or allow SQLite to do full synchronization for you.
Pavel On Tue, Mar 16, 2010 at 5:55 PM, HLS <sant9...@gmail.com> wrote: > Do you know if TLS is used? How does it workout splite3_open_v2() per > thread? Can the handle be used globally? In other words, is open > per thread considered a "different connection?" > > On Tue, Mar 16, 2010 at 3:57 PM, Pavel Ivanov <paiva...@gmail.com> wrote: >> Please be advised that updating/inserting/deleting from the table >> while you're executing select on it has undefined behavior in SQLite >> (if you do that on the same connection) and is considered dangerous. >> Doing that from different connections is possible only if have shared >> cache turned on and read_uncommitted set to 1. If you don't use shared >> cache and turned off locking on VFS level then you can easily get >> database corruption. >> >> Pavel >> >> On Tue, Mar 16, 2010 at 2:12 PM, HLS <sant9...@gmail.com> wrote: >>> Thanks Simon. It just seem so simplistic that SQLITE3 does not allow for >>> >>> Open Cursor >>> for each fetch >>> Issue Update based on ROWID >>> endfor >>> Close Cursor >>> >>> The row fetched is already complete, or the rowid in the table is no >>> longer "sensitive" to anything but a update whether it was opened or >>> not. The "current" cursor is at the next record ready to be fetched, >>> not the one that just been read. So it would seem it would be >>> possible to implement a wrap a lock on the rowid update. >>> >>> I had to see if this is possible with the VFS notes Pavel pointed me >>> to perhaps, or even been looking at the feasibility of changing code >>> (which is the last thing I don't want to do.<g>) >>> >>> On Tue, Mar 16, 2010 at 1:31 PM, Simon Slavin <slav...@bigfraud.org> wrote: >>>> >>>> On 16 Mar 2010, at 5:17pm, HLS wrote: >>>> >>>>> Once approach is to queue any updates/deletes when the database is >>>>> locked with a select request. So when a fetch ends (like in the >>>>> GetNextxxxx function), it will check to see for any pending updates >>>>> and process them. >>>>> >>>>> Does that sound like a viable approach with SQLITE3? >>>>> >>>>> Hmmmmm, this would not address possible client code that can break >>>>> from a loop before reaching the end of select query. >>>> >>>> For the approach that involves queueing write commands, you do definitely >>>> need to know when a SELECT has finished with the database. But SQLite >>>> depends on that anyway, and there's no reason why it shouldn't depend on >>>> correct usage of the API including sqlite3_finalize() . >>>> >>>> I have one installation where it's okay for SELECT commands to return >>>> results which are slightly out of date, but new data becomes available at >>>> sparse and irregular intervals from many sources. Consequently, this >>>> system delays write commands until there has been no access to the >>>> database for one minute (checked by touching a file whenever >>>> sqlite3_prepare() is done). In this particular installation this makes >>>> perfect sense, because the patterns of reads and writes is well >>>> understood. However, for some random installation for a random use of >>>> SQLite it would be disastrous. You may be in a situation where you can >>>> develop a protocol which fits your particular use of SQL very well even >>>> though the solution would be useless for a more general use of SQLite. >>>> >>>> Simon. >>>> _______________________________________________ >>>> sqlite-users mailing list >>>> sqlite-users@sqlite.org >>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>>> >>> >>> >>> >>> -- >>> hls >>> _______________________________________________ >>> 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 >> > > > > -- > hls > _______________________________________________ > 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
