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
