Hi

Some information about my environment:
- Firebird 2.0.3 Superserver (fbserver.exe)
- Windows XP SP2
- Accessed through IBPP
- All connections use TCP/IP to localhost

I have three threads in the client process, each using their own
IBPP::Database object for a connection. The same connection is not shared by
multiple threads.

All threads start their own transaction, created using their own database
object, with access mode read/write (tmWrite), read committed isolation
(ilReadCommitted), no wait lock resolution (lrNoWait), and no special flags.

I get a lock conflict on no wait transaction with the threads in the
following state:

Thread 1:
INSERT INTO MyTable ( MyKey ) VALUES ( 'A' )
* IBPP::Query::Execute has not yet returned

Thread 2:
INSERT INTO MyTable ( MyKey ) VALUES ( 'B' )
* completed
SELECT * FROM MyTable WHERE MyKey = 'B'
* Lock conflict on no wait transaction occurs here

Thread 3:
INSERT INTO MyTable ( MyKey ) VALUES ( 'C' )
* IBPP::Query::Execute has returned


Looking at the Firebird book, this situation doesn't seem to match the first
case for lock conflicts - conflicting UPDATE or DELETE statements in
multiple transactions. The other case, which is caused by using SNAPSHOT
TABLE STABILITY or PROTECTED transaction isolation, doesn't seem to match
either. Changing the transaction isolation to snapshot (ilConcurrency) means
that the lock conflict doesn't happen.

Is the behaviour I'm seeing expected?

That you for your assistance
Gareth Marshall


[Non-text portions of this message have been removed]