Subject | Transactional design with IBO question |
---|---|
Author | hcarvajalsy |
Post date | 2003-04-05T00:08:08Z |
I have a situation where each transaction has to perform various
operations, such as: update a client's balance, update a cashier's
till, insert a journal entry for each item (1 or more) in the
transaction. My proposed solution using IBO Objects is the creation
of a script with the corresponding update or insert statements. My
logical sequence of execution would be:
try
TIB_Script.IB_Connection := TIB_Connection;
TIB_Script.IB_Transaction :=TIB_Transaction;
if not TIB_Transaction.TransactionIsActive
then TIB_Transaction.StartTransaction;
TIB_Script.Execute;
TIB_Transaction.Commit;
except
TIB_Transaction.RollBack;
end;
- my assumption for using a script is to reduce the communication
load, rather than doing a transaction for each update/insert
statement. Does this sounds reasonable?
- I am considering to have generic update/insert stored procedures,
which will be called instead of sending an update/insert SQL
statement. Is it reasonable to assume that this is faster than the
update/insert statement?
- should I add commit statements within the script (possibly as the
last statement in order to avoid a "half" committed script), or
leave the commit to Delphi through the IBO component as it is the
logical sequence above?
- how can I avoid deadlock conflicts using the IBO components under
this scenario? I will have several clients performing transactions.
Can anyone tell me if my assumptions are reasonable or are there
better approaches/suggestions?
Thank you.
Horacio
operations, such as: update a client's balance, update a cashier's
till, insert a journal entry for each item (1 or more) in the
transaction. My proposed solution using IBO Objects is the creation
of a script with the corresponding update or insert statements. My
logical sequence of execution would be:
try
TIB_Script.IB_Connection := TIB_Connection;
TIB_Script.IB_Transaction :=TIB_Transaction;
if not TIB_Transaction.TransactionIsActive
then TIB_Transaction.StartTransaction;
TIB_Script.Execute;
TIB_Transaction.Commit;
except
TIB_Transaction.RollBack;
end;
- my assumption for using a script is to reduce the communication
load, rather than doing a transaction for each update/insert
statement. Does this sounds reasonable?
- I am considering to have generic update/insert stored procedures,
which will be called instead of sending an update/insert SQL
statement. Is it reasonable to assume that this is faster than the
update/insert statement?
- should I add commit statements within the script (possibly as the
last statement in order to avoid a "half" committed script), or
leave the commit to Delphi through the IBO component as it is the
logical sequence above?
- how can I avoid deadlock conflicts using the IBO components under
this scenario? I will have several clients performing transactions.
Can anyone tell me if my assumptions are reasonable or are there
better approaches/suggestions?
Thank you.
Horacio