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 <> 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 <> 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 <> 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
>> --
>> hls
>> _______________________________________________
>> sqlite-users mailing list
> _______________________________________________
> sqlite-users mailing list

sqlite-users mailing list

Reply via email to