Subject | Dangling Transactions? |
---|---|
Author | inoffensive_2009 |
Post date | 2009-09-17T06:45Z |
Hi Folks:
Developing with C++, IBPP 2.5.3.1 and Firebird 2.1.2. Some incarnations of the application will run single user with Embedded Firebird, others will be clients on SuperServer Firebird.
I've instinctively tried to keep transactions as short, in the time the transaction starts until it's committed, as I can.
For inserts and updates, for example, a window representing a row from the database opens, a transaction starts, a row is read, the transaction commits. The user does what they want with the contents of the row, hits "OK" and if the data has changed, a transaction starts, the row is inserted or updated, and the transaction is committed. If the user hits "Cancel", the transaction doesn't even start.
Now I'd like to provide a window where the user can make repeated update operations to the data, query the data and, at the end of the operation, hit the "OK" button to commit, or "Cancel" to roll back the transaction.
I believe this would involve starting a transaction when they open the window, and leave the transaction open for possibly a long time.
I wouldn't be surprised if people go to lunch, or even go home for the weekend, while the window, and transaction, are open. They could even turn off their PC or the server could go down for maintenance and never properly quit the window and commit or roll back the transaction.
Is this a problem? It doesn't seem like a good idea, and I trying to decide if I want to offer a option that will make this demand on Firebird.
Suggestions?
Thanks
Larry
Developing with C++, IBPP 2.5.3.1 and Firebird 2.1.2. Some incarnations of the application will run single user with Embedded Firebird, others will be clients on SuperServer Firebird.
I've instinctively tried to keep transactions as short, in the time the transaction starts until it's committed, as I can.
For inserts and updates, for example, a window representing a row from the database opens, a transaction starts, a row is read, the transaction commits. The user does what they want with the contents of the row, hits "OK" and if the data has changed, a transaction starts, the row is inserted or updated, and the transaction is committed. If the user hits "Cancel", the transaction doesn't even start.
Now I'd like to provide a window where the user can make repeated update operations to the data, query the data and, at the end of the operation, hit the "OK" button to commit, or "Cancel" to roll back the transaction.
I believe this would involve starting a transaction when they open the window, and leave the transaction open for possibly a long time.
I wouldn't be surprised if people go to lunch, or even go home for the weekend, while the window, and transaction, are open. They could even turn off their PC or the server could go down for maintenance and never properly quit the window and commit or roll back the transaction.
Is this a problem? It doesn't seem like a good idea, and I trying to decide if I want to offer a option that will make this demand on Firebird.
Suggestions?
Thanks
Larry