On Oct 15, 2007, at 2:07 PM, Ian Hickson wrote:
On Fri, 5 Oct 2007, Scott Hess wrote:
Reviewing SQLite's error list, the things that MAY have utility to
report more finely might be:
* LOCKED, where you failed because someone else has things locked.
Presumably if a single thread of control tries to open the same
database
via two objects and start two transactions, one of them is going to
lose. Having a transaction fail for this reason seems materially
different from having it fail because the SQL was invalid or
something
of that nature, because the appropriate response might be to retry.
Wouldn't we just want the transaction to wait for the lock to go away?
With upgradeable read-write locks, this can lead to a deadlock.
Consider two transactions that start with a statement that only needs
a read lock. They each grab a non-exclusive read lock and proceed in
parallel. For each, the second statement of the transaction is a
write. Each would like to upgrade its read lock to an exclusive write
lock, but neither can because a shared read lock is still held. At
least one must fail and roll back to avoid deadlock. Thus, it must be
possible for the first write statement in a formerly read-only
transaction to fail.
Regards,
Maciej
