Subject | Transactions |
---|---|
Author | Robert martin |
Post date | 2005-10-18T23:09:15Z |
Hi
Firstly let me apologies if this is the wrong place o post this but here
we go......
We have a app converted from xbase and BDE, using IBO components.
We have been using the built in TIBODatabase transaction. This is set to
tiCommited and AutoCommit (tom mimic BDE functionality) We have
recently noticed a number locking errors
lock conflict on no wait transaction
deadlock
update conflicts with concurrent update
So we are wanting to sort out our transaction handling. We have couple
of procedures that cause this problem most frequently. We thought we
would start by fixing these areas.
We are considering explicitly starting a transaction, placing the whole
transaction in a try except (we are using Delphi) with a rollback at
the end if a conflict occurs. We would then have to code some sort or
retry at a later point, probably including a number of times the
transaction is allowed to retry.
The procedure is quite large and includes a number of tables to be updated.
My questions are (bearing in mind we would like to do this
incrementally)....
1) Is this a reasonable thing to do?
2) What kind of structures would people recommend?
3) Should we use the internal transaction of the try / except / rollback
or should we point all components in this procedure (and any it calls)
to a specific transaction?
4) Any other comments
TIA
--
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Firstly let me apologies if this is the wrong place o post this but here
we go......
We have a app converted from xbase and BDE, using IBO components.
We have been using the built in TIBODatabase transaction. This is set to
tiCommited and AutoCommit (tom mimic BDE functionality) We have
recently noticed a number locking errors
lock conflict on no wait transaction
deadlock
update conflicts with concurrent update
So we are wanting to sort out our transaction handling. We have couple
of procedures that cause this problem most frequently. We thought we
would start by fixing these areas.
We are considering explicitly starting a transaction, placing the whole
transaction in a try except (we are using Delphi) with a rollback at
the end if a conflict occurs. We would then have to code some sort or
retry at a later point, probably including a number of times the
transaction is allowed to retry.
The procedure is quite large and includes a number of tables to be updated.
My questions are (bearing in mind we would like to do this
incrementally)....
1) Is this a reasonable thing to do?
2) What kind of structures would people recommend?
3) Should we use the internal transaction of the try / except / rollback
or should we point all components in this procedure (and any it calls)
to a specific transaction?
4) Any other comments
TIA
--
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd