Problem is trying to get a shared lock in sqlite.c, "static int
winLock(sqlite3_file *id, int locktype)"
at line 37428:
while( cnt-->0 && (res = winLockFile(&pFile->h, SQLITE_LOCKFILE_FLAGS,
PENDING_BYTE, 0, 1, 0))==0 ){
cnt = 2
locktype = 1 //SHARED_LOCK
lastErrno = 6 //ERROR_INVALID_HANDLE
Thoughts?
On 11/3/2015 6:12 PM, Jim Morris wrote:
> I have a connection used by the main (UI) thread and recently added a
> background thread, with own connection(no shared cache) to upload
> changes to server on Windows Mobile 6.0/6.5 devices and upgraded to
> SQLite 3.9.2. The background thread is getting an error 10, extended
> error 3850 as a result of a step when reading a result set in the
> background thread. I'm unclear on the cause of this error.
>
> Is this likely to be a logic error in my code? E.g. locking,
> statements not reset, transactions open or an OS related issue on the
> device. Possibly unrelated, as I recall we needed to go to journal
> mode "PERSIST" years ago to resolve an OS NVFS issue. Most of the
> reads are not in transactions and most of the writes are in
> transactions that are "BEGIN IMMEDIATE TRANSACTION". Busy timeout is
> 30 seconds.
>
> Anyone else still using Windows Mobile 6.x devices?
>
> Is there a graceful work around?
>
>
> (3850) SQLITE_IOERR_LOCK
>
> The SQLITE_IOERR_LOCK error code is an extended error code
> <https://www.sqlite.org/rescode.html#pve> for SQLITE_IOERR
> <https://www.sqlite.org/rescode.html#ioerr> indicating an I/O error in
> the advisory file locking logic. Usually an SQLITE_IOERR_LOCK error
> indicates a problem obtaining a PENDING lock
> <https://www.sqlite.org/lockingv3.html#pending_lock>. However it can
> also indicate miscellaneous locking errors on some of the specialized
> VFSes <https://www.sqlite.org/vfs.html> used on Macs.
>
> Thanks
>
>
>
> On 11/3/2015 10:42 AM, R.Smith wrote:
>>
>>
>> On 2015-11-03 06:31 PM, ALBERT Aur?lien wrote:
>>> Hi,
>>>
>>> I'm often getting the "Database is locked" error message and I don't
>>> really understand what can lead to this.
>>>
>>> I'm using these settings :
>>> - sqlite3_config(SQLITE_CONFIG_MULTITHREAD)
>>> - multiple threads
>>> - only one sqlite connection per thread
>>> - each thread have a different connection instance
>>>
>>> Could anyone clarify some things for me ?
>>>
>>> 1/ Can different threads perform read at the same time (I think yes)
>> Yes - at least, SQLite will handle the requests in a way that seems
>> simultaneous.
>>
>>> 2/ Can different threads perform write at the same time (I think no)
>> Nothing can write simultaneously
>>
>>> 3/ Can a thread perform read while another single one is performing
>>> write ? (I think yes)
>> Depends on the transaction and Journaling mode. See:
>> https://www.sqlite.org/lockingv3.html#writing
>> https://www.sqlite.org/lockingv3.html#rollback
>> In fact, that entire page should be of interest to you.
>>
>> Also, WAL journal mode is inherently good at this. See:
>> https://www.sqlite.org/wal.html#concurrency
>>
>>> 4/ Can a thread perform read while another thread has started a
>>> transaction ? (I think yes)
>> Only if it isn't an exclusive transaction and has not started a write
>> operation, or WAL mode is used, or it is the same connection with
>> read_uncommitted turned on... actually, there are a lot of "if"s here.
>>
>> In general, it is best to view a "Transaction" as a locked state and
>> plan accordingly, and if you absolutely need to read simultaneously
>> from elsewhere, be prepared to take special steps in your code and
>> read up on the modes.
>>
>>> My "Database is locked" problem seems to only appears in situation
>>> number 4, may I am wrong on this one ? Maybe on others ?
>>
>> To put this shortly - you cannot do two things at the same time in a
>> database.
>> Most contentions can be (and are) resolved internally with simple
>> rules, but as soon as a more prominent contention appears (and there
>> are many ways this could happen) then one reader/writer thread will
>> have to wait a little bit until a previous is finished. SQLite's
>> "timeout" setting (as mentioned and linked by Simon already) should
>> fix 99% of these without making you add any extra code.
>>
>> There may be one or two extreme cases or race conditions that
>> requires special consideration, but mostly setting the timeout should
>> suffice. If you still get locked problems - please post again.
>>
>> Cheers,
>> Ryan
>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
