Re: Why a long transaction cannot rollback?? (2)

In article <5igoj2$slt@cssun.mathcs.emory.edu>, johnl@informix.com (Jonathan Leffler) wrote: <snip> >}This is exactly what should happen! LTXHWM=50 & LTXEHWM=60 are figures >}for a multi-user environment (conservative figures, I should mention). > >No, it is not what should happen. >}The logic is very simple. To rollback a transaction, the minimum required >}space in the logical log is the amount used up for the transaction before >}the rollback was initiated. > >Not quite, I think. My understanding is that one CLR (compensation log >record) is written to the log during rollback for each log record generated >by the LTX while it was running. The CLRs are 16 or 20 bytes each. What you say is correct. Apologies. Following some testing, I've found that the CLR record for rolling back INSERTs, DELETEs or UPDATES is 40-45 bytes long (OL v7.20), irrespective of the length of the original record or the type of transaction done. >>Question: when does OnLine test the fullness of the logs against the HWM values? >Online might check the fullness of the logs against the HWM values only >when it switches to a new log. This is correct,too. On testing, I've found that OL uses Log Ids to detect HWM and EHWM. With 6 logs in my test instance, OL invariably aborted when the transaction moved into the x+4 log. It did not matter whether the Tx started at 5% of log x or 95% of log x. Cheers, ----------------------- Rudy Fernandes GIC, Kuwait OL 7.20UC4, 4GL 6.04UC1 -----------------------