| Subject | Statement get stuck and never terminates |
|---|---|
| Author | Marc Bettex |
| Post date | 2012-06-11T07:21:58Z |
Hi everybody,
I'm using Firebird 2.5.1 SuperServer on windows 7 from a .Net application that uses the .Net Ado Provider 2.5.2. The firebird server and the application run on the same machine.
In order to test a component from the application, I create 100 threads that will read, update, insert and delete in the same table in the database during 1 minute. Each thread has its own connection to the database. These statements are run within short transactions (less than 5 statements each) and each statement is limited to a few rows. Moreover, the transactions that only read the data are configured in SNAPSHOT, WAIT, READ ONLY. The transactions that may write data are configured in SNAPSHOT, WAIT, READ WRITE, and lock the table with PROTECTED WRITE.
Around half of the time that I run this test, the server gets stuck executing a statement. By that, I mean that the statement does not terminate. So I have one thread that executes the statement within a transaction that has a lock on the table, and 99 threads that are waiting to open a transaction with a lock on the same table. Things remain stuck forever and the server does not detect any deadlock. The statement on which Firebird is stuck is not always the same. Sometimes it is a SELECT which only reads data, but it is always within a transaction that may write data and is configured as above.
When I query the monitoring tables from ISQL, I see that there are only two transactions (the one executing the statement and the one from ISQL) and that there are only two statements that are executing (the one that is stuck and the one from ISQL to query the monitoring tables). What I noticed, is that in MON$STATEMENTS, the MON$TRANSACTION_ID is <null> for the statement that is stuck. I don't know if this is relevant, but I found this strange, since I'm executing it within a transaction.
I activated the trace log and I'm tracing anything regarding the transactions and the statements. In the log, I can see that the transaction has been started and that the stuck statement has been prepared. But the logs ends here, the statement does not continue with the EXECUTE_STATEMENT_START phase as ususal. Moreover, the trace confirms that the stuck statement is related to the transaction that is in the MON$TRANSACTION table.
The performance monitor shows that Firebird consumes 0% of the CPU and that it does not make any IO to disk or to the network.
This behavior happens only since I updated firebird to version 2.5.1. I had never had it before, and to be sure I reinstalled Firebird 2.1.4 and could not reproduce this behavior.
Would anybody have an idea of why this could be happening or what could I do to find out? I'm running out of ideas to debug this.
Thank you very much and have a nice week,
Marc
I'm using Firebird 2.5.1 SuperServer on windows 7 from a .Net application that uses the .Net Ado Provider 2.5.2. The firebird server and the application run on the same machine.
In order to test a component from the application, I create 100 threads that will read, update, insert and delete in the same table in the database during 1 minute. Each thread has its own connection to the database. These statements are run within short transactions (less than 5 statements each) and each statement is limited to a few rows. Moreover, the transactions that only read the data are configured in SNAPSHOT, WAIT, READ ONLY. The transactions that may write data are configured in SNAPSHOT, WAIT, READ WRITE, and lock the table with PROTECTED WRITE.
Around half of the time that I run this test, the server gets stuck executing a statement. By that, I mean that the statement does not terminate. So I have one thread that executes the statement within a transaction that has a lock on the table, and 99 threads that are waiting to open a transaction with a lock on the same table. Things remain stuck forever and the server does not detect any deadlock. The statement on which Firebird is stuck is not always the same. Sometimes it is a SELECT which only reads data, but it is always within a transaction that may write data and is configured as above.
When I query the monitoring tables from ISQL, I see that there are only two transactions (the one executing the statement and the one from ISQL) and that there are only two statements that are executing (the one that is stuck and the one from ISQL to query the monitoring tables). What I noticed, is that in MON$STATEMENTS, the MON$TRANSACTION_ID is <null> for the statement that is stuck. I don't know if this is relevant, but I found this strange, since I'm executing it within a transaction.
I activated the trace log and I'm tracing anything regarding the transactions and the statements. In the log, I can see that the transaction has been started and that the stuck statement has been prepared. But the logs ends here, the statement does not continue with the EXECUTE_STATEMENT_START phase as ususal. Moreover, the trace confirms that the stuck statement is related to the transaction that is in the MON$TRANSACTION table.
The performance monitor shows that Firebird consumes 0% of the CPU and that it does not make any IO to disk or to the network.
This behavior happens only since I updated firebird to version 2.5.1. I had never had it before, and to be sure I reinstalled Firebird 2.1.4 and could not reproduce this behavior.
Would anybody have an idea of why this could be happening or what could I do to find out? I'm running out of ideas to debug this.
Thank you very much and have a nice week,
Marc