Subject | Transaction deadlock |
---|---|
Author | daniele.barzotti |
Post date | 2010-05-06T19:20:23Z |
Hi,
I have a problem in my client-server application.
My environment is:
VB6 + ADO + Firebird 2.1.3.18185 with latest RC1 release of ODBC.
When the client or the server made a variation on a table, informs the other side to requery its recordsets belonging to that table/query.
I have a lot of table query and all works fine except for a particular table.
The situation is:
1. The client execute a STORE PROCEDURE on TBL_A;
2. The client sends the notification to its windows and to the server;
3. The Server do a requery on a recordset belonging to the same table/query;
3. The Requery locks.
if I use NOWAIT=YES the error is:
"lock conflict on no wait transaction deadlock"
I looking to the MON$ tables and I see that there are pending transactions and statements...
So my question are:
1. Why there is an open transaction? I do not open one explicitly
2. How can I detect if a particular table/query belong to a pending transaction?
3. Or..How can avoid deadlock?
Regards,
Daniele.
I have a problem in my client-server application.
My environment is:
VB6 + ADO + Firebird 2.1.3.18185 with latest RC1 release of ODBC.
When the client or the server made a variation on a table, informs the other side to requery its recordsets belonging to that table/query.
I have a lot of table query and all works fine except for a particular table.
The situation is:
1. The client execute a STORE PROCEDURE on TBL_A;
2. The client sends the notification to its windows and to the server;
3. The Server do a requery on a recordset belonging to the same table/query;
3. The Requery locks.
if I use NOWAIT=YES the error is:
"lock conflict on no wait transaction deadlock"
I looking to the MON$ tables and I see that there are pending transactions and statements...
So my question are:
1. Why there is an open transaction? I do not open one explicitly
2. How can I detect if a particular table/query belong to a pending transaction?
3. Or..How can avoid deadlock?
Regards,
Daniele.