Hello,`
Empirically I found that it is exactly true.
Must admit I'm confused but may it is in line with the Shared-Cache
locking model.
This does not mention the EXCLUSIVE locking state.
The most 'secure' locking state it mentions is a write-transaction
and this can coexist with read-transactions from others.
Thus "begin exclusive" starts a write-transaction and the on-going
read does not interfere.
The error message seems to clarify the situation further: database
table is locked. Thus the collision occurs at the table-level. And
yes, taking different tables for read and write, it does not occur.
Practically this may not help very much. But may be the following
does in case you have a busy_timeout setting.
When having Shared-Cache mode enabled, the timeout setting appears to
be ignored by SQLite. This makes locking situations surface rather
soon, also when there is no dead-lock.
The situation may be handled by a programmatic retry?
Regards, Ed
Op 19-dec-2007, om 19:12 heeft Ken het volgende geschreven:
Some additional info:
when the sqlite_lock is returned there is another thread that
appears to be reading the same table. Does the sqlite3 step return
sqlite_locked in this case?
Thanks,
Ken
Ken <[EMAIL PROTECTED]> wrote:
While using the new 3.5.4 sqlite3_enable_shared_cache I ran into a
strange lock situation.
SQLITE_LOCK is returned from an insert statement, even though
the thread/connection performed a successful "begin exclusive"
transaction.
begin exclusive
insert into table... ---> returns SQLITE_LOCKED
Is it possible for both connections to begin exclusive transactions
whilst having the shared cache anabled?
Thanks,
ken
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
