Kbase P21548: The Run Time aspect of Transactions, the TRANSACTION keyword can only ENLARGE the scope
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/15/2008 |
|
Status: Verified
GOAL:
The Run Time aspect of Transactions
GOAL:
Does the TRANSACTION keyword narrow down the transaction scope?
GOAL:
When investigating Transaction Scope in program listings
FIX:
Developers are often confused about their listing regarding transactions or about the TRANSACTION keyword. Indeed, starting a DO TRANSACTION: block does not mean that the block will be handled as a separate transaction, but as a new sub transaction if a transaction was already active, as illustrated below:
/* ThisProgramNeverEndsItsTransactionByMistake.p */
FIND FIRST MyTable EXCLUSIVE-LOCK.
MyTable.AnyField = "NewValue". /* assign not even necessary to */
/* start a transaction */
MESSAGE TRANSACTION VIEW-AS ALERT-BOX INFO BUTTONS OK. /* reports YES */
RUN UpdateOrder.p.
/* UpdateOrder.p */
FOR EACH order EXCLUSIVE: /* one transaction per iteration */
order.instruction = order.instruction + " updated instruction".
END.
UpdateOrder.p will update each order in a separate sub-transaction, but all the order records will be handled in one single big transaction because a transaction was already active before running it. This may overload the Lock Table (see -L Parameter) and lead to error 915.
Doing FOR EACH order EXCLUSIVE-LOCK TRANSACTION: does not change the situation and is actually useless because a FOR EACH block already has an iterative transaction property.
The ThisProgramNeverEndsItsTransactionByMistake.p code given above is often done by mistake and the too large transaction problem can be solved with the following:
DO TRANSACTION:
FIND FIRST MyTable EXCLUSIVE-LOCK.
MyTable.AnyField = "NewValue". /* The transaction is already started, */
/* the point of ASSIGN is just to */
/* illustrate a need* */
RELEASE MyTable. /* The point of the RELEASE is to not */
/* keep an undesired SHARED-LOCK on */
/* the record after the END. */
/* A SHARED-LOCK would not keep the */
/* transaction active but it would */
/* unnecessarily load the system. */
END. /* Now the transaction is finished */
MESSAGE TRANSACTION VIEW-AS ALERT-BOX INFO BUTTONS OK. /* reports NO */
RUN UpdateOrder.p. /* Now this program will handle a */
/* separate transaction for each order */
Note that still to avoid an unwanted SHARED-LOCK, the RELEASE could be:
- Replaced by a FIND CURRENT MyTable NO-LOCK (so record remains available without any lock after the END)
- Just removed, but you should then limit the Scope of the MyTable buffer to the block with DO FOR MyTable TRANSACTION: (strong scope block).
As a conclusion:
A) The TRANSACTION keyword can only:
1) Start a new sub transaction
2) Enlarge the TRANSACTION scope of a block by making on single transaction block with multiple sub transaction blocks
B) Transactions have a run time aspect:
1) They cannot only be investigated with listings.
2) The following can be used to investigate transaction problems:
2.1) The TRANSACTION 4GL function
2.2) The Promon (transaction menu, or Lock Table)
2.3) The Virtual System Tables _Trans and _Lock