[GemStone-Smalltalk] A question about #transactionless mode

[Paul Baumann]

If you go transactionless (and without aborts) then your reports would show the same data until enough CR backlog accumulates for the gem's view to be updated. Your reports would not be as current and you'd be allowing CR accumulation and then causing the server to have to manage views though a longer series of changes. If you go transactionless (with aborts) then your reports would show timely information and would allow for data to be refreshed when a report is taking too long to generate. If there is a long gap between report runs then being transactionless automatically avoids holding the oldest CR, but it still allows CR accumulation which is slow to resolve through. Whether in transaction or not, server performance is improved from minimizing the number of change records the server needs to resolve though; it means doing periodic aborts before the server demands them and according to your own control.

It sounds like your reports are currently run in automatic transaction mode, are accurate, and have never caused a problem from years of running that way. If the reporting gem is not involved in holding a CR backlog then I don't see an advantage to making it transactionless. If the report had a bug that allowed infinite recursion then running transactionless would allow it to trudge on consuming CPU without ever being terminated for holding the oldest CR too long. Not a strong reason for avoiding transactionless mode, but not a good argument for it either. An argument against using transactionless can be that some enumerations would fail if the size unexpectedly changes during the enumeration. It is better to have control over when objects change.

Paul Baumann


From: gemstone-smalltalk-bounces at lists.gemtalksystems.com [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of Kevin Szabo
Sent: Tuesday, October 29, 2013 02:28
To: gemstone-smalltalk at lists.gemtalksystems.com
Subject: [GemStone-Smalltalk] A question about #transactionless mode


Hello again GemStone folks,
I am supporting a system that has a number of reporting TOPAZ scripts kicked off by CRON.  Many of these scripts were written a decade or so ago, and of course, still work perfectly because that is just what GemStone does.
Some of the scripts are using the default transaction Automatic (since I see their state as #autoBegin).  This was the time before #transactionless mode.

I am considering moving them to #transactionless since they do read-only reports on the database.  However, I need someone to help me with the interpretation of the manual on this.  When I run #transactionless all appears to work correctly, but according to some documents I should not do this because I have an unstable view on the database?  Is this correct?  Should I set to transactionless, do a beginTransaction (to get a stable view), run my report, and then abort the transaction?
Some of the reports generated don't have to be completely accurate.  That is, if I am measuring the size of a work queue I don't mind if there is some fuzziness in the length reported.  I just care if the queue is 10, 100, or 10,000.  I don't need the exact length, because it has changed by the time the report finished anyway.  Also, I would like to run this report fairly frequently (to update a web display of system health) so I prefer fast and fuzzy rather than slow and exact.
Thanks for any thoughts on this.
Regards,
Kevin Szabo.
P.S.  I still enjoy amazing up-times and tremendous reliability.

________________________________
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20131029/243572a2/attachment-0001.html>