[Glass] Nested transactions and 'CorruptObj error', or: how to abort in GLASS?

[Johan Brichau]

Pieter,

The GLASS setup makes the use of transactions transparant. That means you can run a Seaside application just as if you would be relying on image persistence.
imho, that makes for a great out-of-the-box experience. Of course, that also means that when you want to control the transactions, you need to understand how the transparant persistency works.

Once you have more specific requirements, it is not hard to find out where Seaside in GLASS is wrapping the transactions and work with them.
That is exactly what we do using the DALi framework [1,2] for Yesplan. It was designed to abstract the differences between how we can do transactions with OODBs like GOODS in Pharo and the 'transaction-per-request' approach in GLASS. 

Some of the things you describe fit with how we work with DALi. Things like aborting a transaction and popping up an error message or 'lightweight' nested transactions (i.e. tracking changes to our own objects). However, I think I will need to write up more elaborate documentation about it to make it more usable for outsiders. Also, it does not fit all cases you describe and you need to build the application with the DALI framework in mind, so I have never been sure if it was really applicable to others, but it would seem so....

Johan

[1] http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/Dali
[2] http://ss3.gemstone.com/ss/DALi.html/Overview

On 20 Mar 2014, at 14:26, Pieter Nagel <pieter at nagel.co.za> wrote:

> I find this state most perplexing.
> 
> The whole point of running a Seaside application in GemStone, as opposed
> to, say, Pharo, is that GemStone offers persistence. And transactions
> are a large part of persistence, so saying "it is best to avoid
> transactions altogether" negates a large part of the value proposition
> that GemStone offers in the first place.
> 
> Frankly, I would expect GemStone to *promote* the use of transactions,
> to further leverage what differentiates you from other options. If there
> are tricky implementations details, I'd expect you to rather steer
> people towards using transactions at the right level than pinning a
> "caveat emptor" disclaimer on them.