Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
transaction timeout |
Tue, Dec 20 2016 3:40 AM | Permanent Link |
Graham Mylne | is there a transaction timeout?
If i start a transaction and leave it running it never stops so the database is in a constant lock state. So curious if there is a timeout for this? Obviously the main issue is that my application never pulls out and keeps holding the transaction which i am investigating but is there some sort of way of timing out a transaction? |
Tue, Dec 20 2016 4:04 AM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | Graham Mylne:
Yes, there is. You have to change the property TableTransLockRetryCount in the Engine For example: Engine.TableTransLockRetryCount := 10000; // it represents 30 seconds (10000 x 3) This must be set before the Engine become active |
Tue, Dec 20 2016 4:59 PM | Permanent Link |
Graham Mylne | that just handles when there is a transaction already started and the lock retries attempted for waiting, this is the first transaction started and so it is not waiting on any other process. It has start the transaction fine but nothing tells it to stop after x amount of time.
|
Tue, Dec 20 2016 7:58 PM | Permanent Link |
Raul Team Elevate | On 12/20/2016 3:40 AM, Graham Mylne wrote:
> is there a transaction timeout? Generally no. If you're using a C/S (dbsrvr) and is later cleaned up by dead session logic i believe transaction is rolled back (not 100% on this though). > If i start a transaction and leave it running it never stops so the database is in a constant lock state. So curious if there is a timeout for this? Obviously the main issue is that my application never pulls out and keeps holding the transaction which i am investigating but is there some sort of way of timing out a transaction? You should not leave a transaction running - they are meant to be short operations and as a developer you need to ensure that it's always committed or rolled back (for example in case of exception(s) or other errors). Raul |
Tue, Dec 20 2016 8:00 PM | Permanent Link |
Raul Team Elevate | On 12/20/2016 7:58 PM, Raul wrote:
> If you're using a C/S (dbsrvr) and is later cleaned up by dead session > logic i believe transaction is rolled back (not 100% on this though). Meant if you're using C/S and your session dies in the middle of a transaction and is later cleaned up it should roll it back. Should be same if you were to force your connection closed. As i said do check on this. Raul |
Tue, Dec 20 2016 8:54 PM | Permanent Link |
Graham Mylne | transactions are supposed to be short and sweat but we seem to get the occassional client that is keeping its transaction in motion and because it has a ping and not disconnecting the transaction remains open until we close the session. I had the feeling there is no timeout, i feel i will need to log the clients further and work out what transaction they are starting and why it is not calling commit or progressing. Its like they call start transaction then halt any further code from running.
|
Wed, Dec 28 2016 2:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Graham,
<< transactions are supposed to be short and sweat but we seem to get the occassional client that is keeping its transaction in motion and because it has a ping and not disconnecting the transaction remains open until we close the session. I had the feeling there is no timeout, i feel i will need to log the clients further and work out what transaction they are starting and why it is not calling commit or progressing. Its like they call start transaction then halt any further code from running. >> You should make sure that all transactions initiated on the client are using a try..except block to ensure that a transaction is always rolled back or committed, with the only exception being that the client application was killed. In such a case, the DBISAM Database Server dead session parameters will be your key to making sure that a dead session is removed ASAP. MyDatabase.StartTransaction; try // Do something MyDatabase.Commit; except MyDatabase.Rollback; raise; end; Tim Young Elevate Software www.elevatesoft.com |
Thu, Dec 29 2016 4:55 PM | Permanent Link |
Graham Mylne | thanks Tim, that is what we had but i think i found some logic within the exception that was preventing the rollback process and keeping the session locked. We are testing it out now, should hopefully be sorted now, thanks.
|
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |