Bug #10041
Extend usages of TransactionManager.honorStopCondition to tight loops inside the run-time
0%
History
#1 Updated by Alexandru Lungu about 1 year ago
- Subject changed from Extent usages of TransactionManager.honorStopCondition to tight loops inside the run-time to Extend usages of TransactionManager.honorStopCondition to tight loops inside the run-time
This is a deferred discussion from #10000-59.
In #10000 I added the possibility to interrupt threads that are RUNNABLE. This will set a flag to the thread that will be eventually honored by TransactionManager.honorStopCondition. However, this construct occurs only at blocks start and in 2j.persist.Presorter$SortedResults. The suggestion is to use this construct more in other tight loops like CompoundQuery.retrieveImpl or other "risky" loops. Such loops can get in infinite iterations due to various reasons: misconfiguration (collation of database combined with invalidation), id reclaiming, etc. Ideally these should not occur as bugs in FWD, but they seem to pop up occasionally. The after-effect is the need to do a server restart.
#3 Updated by Constantin Asofiei about 1 year ago
To reiterate something I mentioned during the standup today: in OE, when you kill the OS process for a frozen GUI client, then that is terminated; and done. It doesn't matter what 4GL code was running at the time, and the database server is responsible of rolling back the transaction.
In FWD, the client work is on the FWD server. If an administrator wants to terminate that client, then FWD should allow it, regardless of what the session is doing at that time. Instead of a STOP condition, we should maybe raise a different exception, similar to ApplicationRequestedStop, which unwinds the stack without a chance for the 4GL converted code to have an DO ON STOP UNDO, NEXT and ignore it.