Bill King wrote:
It would be nice if SQLite told us this. However, SQLite detects the
reserved lock and returns SQLITE_BUSY, telling niether transaction
much other than to try again. If a reserved lock is detected when
trying to promote an existing read lock, this is a deadlock situation
and should perhaps return an error code of SQLITE_DEADLOCK instead?
Christian
According to DRH this scenario shouldn't happen. Begin should set a
flag, and the second begin will bug out because the flag is set. This is
what looks like happening in my scenario, and is definately wrong
behaviour. begin should be just that begin, mutually exclusive, unless
Dr Hipp want's to implement versioning based transaction schemes. Not,
begin "maybe i'm read, maybe i'm write, i'll decide later and woe betide
any one else who tries to write".
It may be wrong behavior, but that's how SQLite works. Sometimes you
just have to learn the quirks of the system and then deal with them.
File a bug report or submit a patch with the "correct" behavior and I am
sure DRH will be more than happy to review it.
--
Craig Morrison
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://pse.2cah.com
Controlling pseudoephedrine purchases.
http://www.mtsprofessional.com/
A Win32 email server that works for You.
