G
George Potemkin
Guest
When transaction is interrupted by a signal it will be backed out, a session will log out from a database and… process will keep running for a while: the time of its life after logout equals approximately 50-80% of transaction’s duration. The common terminating signals that can interrupt a Progress session can be divided into two groups - "stoppers" and "terminators". "Stoppers": SIGINT, SIGPIPE, STOP and UNDO statements in 4GL (4GL statements are not the signals but anyway..). "Terminators": SIGHUP, SIGQUIT, SIGTERM and proshut -C disconnect These groups are different in many aspects: Duration of transaction undo triggered by a "stopper" is just a bit longer than transaction duration (an undo adds BI reads). Undo initiated by a "terminator" is much faster - 25-50% of transaction duration (the factor varies with transaction size). It’s the same time that broker/watchdog will spend on transaction undo if a session was terminated by SIGKILL. If a session has opened the transactions in a few databases then all transactions will be undone one transaction in time, in other words, a session will be temporary "frozen" in all databases except one. Transaction backouts initiated by the "stoppers" will be done in the order in which a session has been connected to the databases. Transaction backouts initiated by the "terminators" will be done in the /reverse/ order: the last connected database will be the first one backed out. The different scenarios, the different undo times - does it mean the different algorithms that Progress is using to undo the transactions depending on the trappable or untrappable STOP conditions? "Stoppers" do not set neither the "usertodie" flag (_Connect-Disconnect) nor the "resyncing" flag (btw, it’s not reported by _Connect-Interrupt - is it a bug?). "Terminators" set the "usertodie" flags in all databases (except, of course, proshut -C disconnect that does it only for one database) and set the "resyncing" flag for the last connected database - the starting point of transaction undoes. "Terminators" cause a session to write the backout messages to a log of the corresponding database (even if transaction was in the ALLOCATED status, i.e. when the transaction did not really change a database): (2252) Begin transaction backout. (2253) Transaction backout completed. Of course, "stoppers" do not leave such messages. If 4GL code is trapping the STOP condition and quits on STOP (IF RETRY THEN QUIT) then a session is terminated immediately after logout from the last connected database. The "stoppers" (except SIGHUP) leave a session on pause. For example: KILL signal received. (298) Press space bar to continue. The message really means "Press space bar to terminate the session". The common signals ("stopper" or "terminator") will terminate a session in this state. Let’s treat this state as an end of session’s execution. Between this state and the logout from the last database (= first connected database) the session keeps running for a while. Example: [2018/05/12@09:24:19.113+0400] P-1135 T-140073628817216 I ABL 8: (452) Login by root on /dev/pts/27. [2018/05/12@09:24:19.115+0400] P-1135 T-140073628817216 I ABL 8: (7129) Usr 8 set name to root. [2018/05/12@09:24:19.224+0400] P-1135 Transaction begins. [2018/05/12@09:25:19.228+0400] P-1135 Transaction is ready. [2018/05/12@09:25:47.000+0400] kill -HUP 1135 [2018/05/12@05:25:47.000+0000] P-1135 T-140073628817216 I ABL 8: (562) HANGUP signal received. [2018/05/12@09:25:47.117+0400] P-1135 T-140073628817216 I ABL 8: (2252) Begin transaction backout. [2018/05/12@09:26:09.014+0400] P-1135 T-140073628817216 I ABL 8: (2253) Transaction backout completed. [2018/05/12@09:26:09.014+0400] P-1135 T-140073628817216 I ABL 8: (453) Logout by root on /dev/pts/27. [2018/05/12@09:26:53.000+0400] P-1135 is terminated. Tran Time: 60.004 sec Undo Time: 21.897 sec Time after logout: 43.986 sec Note: Undo + Time after logout seems to be always a bit longer that transaction duration. "P-1135 is terminated" was reported by: while sleep 1 do kill -0 $PID 2>/dev/null && continue echo [`date '+%Y/%m/%d@%H:%M:%S.000%z'`] P-$PID is terminated. >>$LOG break done & Stack trace of a process after logout shows the calls: fgetcxdll freadxdll frdfrom bfundo bfrej rnxitn_noval rninterpret rnrq main I can be wrong but it looks like a process is reading lbi file. The size of lbi file created during transaction is almost twice (1.8-1.9 times) higher than the number of bytes written to BI file by transaction before it was interrupted. Lbi file is not growing during transaction undo. The size of lbi file is only slightly (700-800 bytes) increasing after database logout. I did not use the -nosavepoint parameter during the tests. The -lbimod parameter also has the default value. If a session does read its lbi file at the final phase then it reads only the part of it related to the interrupted transactions. Anyway it’s not clear why process does not terminate immediately after logout from the last database. Of course, it’s a minor issue because after logout a process is not using database resources. We can safely use SIGKILL to terminate a process provided we are 100% sure that a session is not connected to any other databases. But we will have 100% insurance only when a process is terminated. Tested with 11.7.2 on Linux and HP-UX
Continue reading...
Continue reading...
