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

[Pieter Nagel]

TLDR: how is a GLASS app supposed to handling aborting?

Our biggest headache porting from GS64 2.4 to 3.1.0.4 relates to aborting.
 Specifically, we have code that does a batch of operations, bulks up all
error messages, and if there were any errors, wants to abort all side
effects of the batch and show an error message.

Currently, under 2.4, "System rollbackDirtyList: System dirtyListId" is
used to abort. This was done (apparently on the recommendation of this
mailing list) as a work-around for the fact that "System abortTransaction"
breaks horribly - it seems to cause the Seaside machinery and adaptors to
lose state about the very request that is being handled. But "System
rollbackDirtyList" no longer exists in 3.1.

The only "blessed" infrastructure for aborting that seems to be provided
in GLASS on 2.4 is SafelyPerformBlockRequiringAbort. But the block that
one can "safely perform" is called outside of the Seaside request handling
stack, so one can't do any interesting processing like call:'ing a new
component that shows an error message. Also, it is hard-wired to retry the
same request again, where in our case that would just lead to re-doing the
same batch of operations that would just lead to the same errors and the
same need to abort again.

GS 3.1 introduces nested transactions, which on the surface would seem to
be the ideal mechanism to handle these kinds of requirements.

Ideally, the GLASS infrastructure would enter a nested transaction at a
suitable boundary before running end-user code, so an application can just
abort its own subtransaction if it wants to.

We first went the route of just wrapping our batch process in a block that
enters a nested transaction, aborts on exceptions (and re-raises the
exception, or commits otherwise. But this causes horrible Heisenbugs,
where at best the current session becomes unusable, and at worst the stone
file is corrupt.

The problems we're having seem similar to the fixed OBJ_ERR_CORRUPT_OBJ
bugs mentioned in the 3.1.0.5 release notes (even though not explicitly
saying that they are related to nested transaction), so I'm first going to
take that for a spin.

But in the meantime: is our intended use of subtransactions within the
scope of "sanctioned behaviour" on GLASS?