[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Transactions and Undos. Novel

Status
Not open for further replies.
G

George Potemkin

Guest
Chapter 2: Types of UNDOs Posted by Gus Bjorklund on 15 May 2018 community.progress.com/.../119631 Remember that transactions are an /error handling/ mechanism. There are really four variants of undo in the client (plus two in the database, but that is another topic). they are: 0) undo triggered by an error condition detected in application logic and execution of an UNDO statement, 1) undo triggered by some error condition like a duplicate key, 2) undo triggered by a stop condition, 3) undo and termination triggered by an error detected by a signal handler. The LBI file is used to record client-side history so that some or all actions can be undone. In all cases, there may or may not be LBI reading to accompany the undo action. The LBI file is composed of one or more nested “AR units” or “action-recovery units”. An AR unit matches execution of a block in the 4GL. One AR unit may align with a block that has a database transaction and that does not have to be the outermost AR unit. Only one because database transactions cannot be nested in the 4GL. Subsequent AR units will be sub-transactions and their database actions may be recorded in the LBI file or not if database savepoints are being used by the client. Also, a nested AR unit may involve the start of a transaction on another database. When that happens, the second database transaction “joins” the outer one in a sense. While actions on the second database can be undone, that transaction can’t be committed until the outer database transaction commits. Along with block nesting, the LBI file is used to record values of local variables, temp table actions, database actions, buffer connections and disconnections and a few other items related to client side state information. During forward processing, the LBI file is buffered in memory and written sequentially when the buffer fills. When an undo happens, the LBI is read backwards from eof and a new eof established when the undo is finished. Depending on how much is being undone, the new eof may be at the beginning of the LBI or at the start of some block’s AR unit. When an undo happens, the undo may go back to any active AR unit. The target AR unit may be the same one that matches a database transaction, higher, or lower. In the first four cases mentioned above, the 4GL session will or can continue, depending on the application logic. The undo processing is very similar for all of them, except that a stop condition may be triggered by a lost database connection. In such a case, database actions in sub-transactions cannot be undone by the client. undo must include the AR unit for the outermost database transaction but may go farther than that but not does necessarily stop the session. In the last case, the client session is going to be terminated due to a fatal error. Much of the undo processing is the same as above, except that it goes all the way to the outermost AR-unit and then the client will exit. In some cases, depending on the type of error (e.g. an access violation), undo processing consists only of rolling back the database transaction followed by database disconnect and process exit. I’m sure I have left out something important but I cannot remember what it is. If a session has opened the transactions in a few databases then these transactions will be undone one by one, in other words, the transactions will be temporary "frozen" in all databases except one. Signals can trigger an undo only of the whole transaction. ABL events can trigger an undo of the sub-transactions. In case of remote client an undo is performed by remote server: client session sends one short message to its server. When undo is completed the server sends one message back to the client. The exception is the undo of sub-transaction initiated by a client’s session started with the -nosavepoint. In this case the session will send one message per each recovery note generated by server. Undo of the whole transaction initiated by session with the -nosavepoint is performed the same ways as without the -nosavepoint - server will receive only two messages from a client and will send one message back. When a client’s session is not using the -nosavepoint the RL_TMSAVE notes are generated also during undo phase. Undo of transaction or sub-transaction can’t be interrupted. If a session will get a signal during UNDO phase the action will be postponed until UNDO is completed. The signals-terminators (SIGINT, SIGQUIT, SIGPIPE, SIGTERM) received after the SIGHUP signal will be completely ignored because SIGHUP will be moved from SigCgt (the caught signals) to SigIgn (the ignored signals). On Linux, for example, you can see the signal masks in /proc/$PID/status file. Other types of the signals should be processed even after SIGHUP. If an undo of sub-transaction is successfully completed then its recovery notes will be ignored during undo of the whole transaction – as if they do not exist at all in BI file. Probably Progress writes a jump note at the end of sub-transaction’s undo. I guess it was the original aim of the jump notes. The UNDO triggered by an event inside ABL session or by SIGINT, SIGPIPE signals (“stoppers”): Transaction backouts will be done in the order in which a session has been connected to the databases: the first connected database will be the first one backed out. Duration of undo will closely match the duration of FWD phase. The UNDO triggered by the signals-terminators (SIGHUP, SIGQUIT, SIGTERM and proshut -C disconnect): Session sets the "usertodie" flag in Usrctl Table (_Connect-Disconnect). Transaction backouts will be done in the reverse order: the last connected database will be the first one backed out. Session sets the "resyncing" flag (_Connect-Resync) only in database where undo is currently running. When the "resyncing" flag is set ON/OFF the backout messages is written to a database log: (2252) Begin transaction backout. (2253) Transaction backout completed. Duration of undo will be 25-50% of transaction duration. Session will keep running for a while after logout from all databases. There is a case when it becomes a problem: if session got a fatal error during an undo the watchdog will not release the resources locked by session until the process still exists in the system.

Continue reading...
 
Status
Not open for further replies.
Top