The JADE 2022 release meets tomorrow’s business demands.
Currently, when you run a simple test of abortTransientTransaction (like the example below), it would appear that it works.
Comments added to JAD-I-398 were based on the impression abortTransientTransaction appeared to work, however the JADE Plant have since clarified that it's not fully implemented.
A simple test like the example below work provided the object doesn't overflow, as a private/in-memory copy is used & rolled back. If the shared transient objects updated do overflow, then changes aren't rolled back as you'd expect.
It'd be good if this were implemented which'll give us more opportunity to make use of it in scenarios where we want to handle processing in-memory using a shared transient cache. But I also believe it should be implemented to ensure consistent behaviour, as there's a risk systems already using abortTransientTransaction may not behave as expected, where the developer has used abortTransientTransaction on the assumption it works as advertised, which may have appear to be the case during testing, but in production/busy environments may well behave different when objects overflow.
object : TestObject;
create object sharedTransient;
object.number := 1;
write object.number.String & " (before test)";
object.number := 2;
write object.number.String & " (before abort)";
write object.number.String & " (after abort)";