The JADE 2022 release meets tomorrow’s business demands.
Update locks are great for reducing deadlocks and reducing contention, but they only work on persistent objects. Attempting to obtain an update lock on a shared transient instance gives an 1107 exception : The current operation cannot be performed on a transient instance
Craig Shearer
Please note: abortTransientTransaction does not work as expected in all circumstances. A shared-transient object is updated in a private local copy of the object. This copy is thrown away if the transaction is aborted. Where the problem arises is if the object is overflowed from the cache. There is no rollback in the shared transient database that the object has been overflowed to. If this happens (the updated object overflows) and the shared transient transient is aborted the update is not undone.
Attachments Open full size
I take it back! We've just discovered abortTransientTransaction does actually work now, seemingly as far back as JADE 7.0 at least (don't have an older base on hand to check an earlier version), but we're pretty sure it didn't always work. Perhaps the JADE Plant could clarify when it was implemented?
Attachments Open full size
I suspect this isn't supported for the same reason abortTransientTransaction isn't actually implemented, because updates to the objects in memory have already taken effect & cannot be rolled back. Without the ability to isolate the transaction for a rollback, there'd also be no way of maintaining the original version of a shared transient for other processes to read while a process has an update lock.
Rather than raising the 1107 exception in this scenario, the update lock could be treated as an exclusive lock instead. This'll allow us to code things as if it's supported, just like we do with abortTransientTransaction, until such time as support can be implemented for isolating transient transactions.
Attachments Open full size