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

[Pieter Nagel]

Dale,

I'll get back to you on the C stacktrace when I'm back on site next
week, if the client is willing to sink more time into this (there's talk
of getting around the problem by ditching transactions and following the
"look before you leap" idiom, so the code can be semantically equivalent
under Pharo, which would have value to us in and of itself).

However:

On Wed, 2014-03-19 at 13:47 -0700, Dale Henrichs wrote:

> Yes doing an abort "out-of-school" in the seaside stack is not really
a good idea ...  commits  aren't a real good idea, so it is best to
avoid transactions altogether ...

and

>  ... I'd be inclined to not offer [transactions] as a standard
capability ... avoiding all transactions is best...

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.

-- 
Pieter Nagel