[GemStone-Smalltalk] A question about #transactionless mode

[James Foster]

Hi Kevin,

Transactionless mode is discussed on pages 144-46 of the Programming Guide (found at http://gemtalksystems.com/index.php/community/gss-support/documentation/gs64/).

In general, the system keeps a consistent view of the database and you control when the view changes with an abort or commit. Because there is overhead in keeping a unique view, it is costly to the system if you stay on an old view after everyone else has moved ahead. The “commit record backlog” is one of the first things we look at when people have problems with their database.

Selecting ‘transactionless’ mode is a way to tell the system that you are willing to let the system perform an abort anytime you are on the oldest commit record (to move you to the newest one). As described in the documentation, this would typically be reasonable for an idle session. 

The risk of an “unstable” view of the database is that if you perform an operation that looks at data across multiple transactions there can be an inconsistency. The typical example is with bank accounts where if you looked at the balance in my savings account, then (in a single transaction) I transferred funds from savings to checking, and then (in a later view) you looked at the balance in my checking account, you would get an incorrect idea of how much money I have in total. It is in this way that the database is “unstable.” That is, the values might not be consistent in a logical sense; there is nothing “unstable” in the sense that you could do physical harm to the database.

Depending on the operation, this “instability” might not be a problem. If you wait till after midnight and then do an analysis of all the transactions that took place yesterday, then subsequent transactions will never (logically) affect what you see and your analysis will always be the same as if you were in a single transaction.

Transactionless mode only has meaning when you are not in a transaction. If you begin a transaction (whether in auto, manual, or transactionless mode), you are in a transaction and will stay in that exact transaction until you commit or abort. Thus, you lose the “benefit” of telling the system that it may advance your view if you are behind the rest.

Do you have an idea of how long the report takes to run and how many other transaction are typically done during that time? If it takes a minute to run and there are 20 other transactions, then you shouldn’t worry about a commit record backlog. If it takes 30 minutes to run and there are 20000 other transactions, then you should be (very) worried.

James

On Oct 29, 2013, at 3:27 AM, Kevin Szabo <k.s.szabo at gmail.com> wrote:

> 
> 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.
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20131029/f7d74c7d/attachment.html>