Subject | SELECT FOR UPDATE WITH LOCK and Connections |
---|---|
Author | sasidhardoc |
Post date | 2006-11-01T21:05:20Z |
I have a Firebird DB with remote clients connecting via TCP/IP. The
clients use ADO.NET
In the DB, there is a SP which is similar to:
SELECT f1, f2 FROM T1 FOR UPDATE WITH LOCK
Client 1 starts a transaction, and then retrieves using the SP.
If Client 2 now starts a transaction and retrieves using the same SP,
I get a "locked record error" - which is the expected behavior.
If client 1 starts, and I pull the network cable on client 1 after
transaction has started, then Client 2 runs a transaction to retrieve
the SP, I still get a "locked record error".
With a similar scenario in MS SQL, transaction 1 will get rolled back
(and the lock released) when I pull the network cable. Is the behavior
in Firebird different by design? What can I do to roll back the
transaction and release the lock when a client drops a connection?
I am using superserver. The transactions run with options NoWait,
ReadCommitted, RecVersion. TIA
clients use ADO.NET
In the DB, there is a SP which is similar to:
SELECT f1, f2 FROM T1 FOR UPDATE WITH LOCK
Client 1 starts a transaction, and then retrieves using the SP.
If Client 2 now starts a transaction and retrieves using the same SP,
I get a "locked record error" - which is the expected behavior.
If client 1 starts, and I pull the network cable on client 1 after
transaction has started, then Client 2 runs a transaction to retrieve
the SP, I still get a "locked record error".
With a similar scenario in MS SQL, transaction 1 will get rolled back
(and the lock released) when I pull the network cable. Is the behavior
in Firebird different by design? What can I do to roll back the
transaction and release the lock when a client drops a connection?
I am using superserver. The transactions run with options NoWait,
ReadCommitted, RecVersion. TIA