Commented by: @dyemanov

Locks are owned by attachments and attachment cannot wait for itself (it will cause an infinite deadlock), so conflict error is raised immediately if both lock requests belong to the same owner. This is a design limitation rather than a bug.

Commented by: @dyemanov

I'm wondering what you expected from this test case? The only alternative is to hang your application forever "waiting" for the first transaction.

Commented by: Gabor Boros (gaborboros)

So, cannot use two transactions (in this example a reader and a writer) in same attachment in same time by design? "raised immediately"? For me with the attached example exception raised after ~10 seconds (come from DeadlockTimeout in firebird.conf?).

Commented by: @dyemanov

Yes, this is by design. Two conflicting transactions cannot wait for each other inside a single attachment. Deadlock is really detected after the DeadlockTimeout interval.

Commented by: Gabor Boros (gaborboros)

Yes, for me the WAIT transaction means wait "forever" (and continue if the concurrent transaction committed/rollbacked). Which works if the reader and writer transaction separated to two attachments. For the WAIT transaction MON$TRANSACTIONS.MON$LOCK_TIMEOUT value is -1 and Language Reference say "-1 - wait forever".

Commented by: @dyemanov

With two separate attachments, you can "unblock" the waiting transaction by committing / rolling back the blocking transaction. It's impossible if they both belong to the same attachment. In this case WAIT = HANG and the engine detects this signaling a deadlock.

Commented by: Gabor Boros (gaborboros)

Is this "by design" documented somewhere or trivial for everybody except me? :-) Please close this issue...

Commented by: Attila Molnár (e_pluribus_unum)

Hi Gábor!

http://firebirdsql.org/file/documentation/drivers_documentation/python/3.3.0/thread-safety-overview.html

Definition of "Thread-Safety"

Currently, the highest level of concurrency supported by any version of the Firebird client library is thread-safety at the connection level.

When we say that the Firebird client library is thread-safe at the connection level, we mean that it is safe to use a particular connection in only one thread at a time, although the same connection can be manipulated by different threads in a serial fashion, and different connections can be manipulated by different threads in parallel.