JADE Environment Development Ideas

What's new in the upcoming JADE release?


The JADE 2022 release meets tomorrow’s business demands.

Start your update to JADE's latest release

updateLock should work on Shared Transients

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
  • Jun 12 2019
  • Future consideration
  • Attach files
  • Nick Scott commented
    19 Dec, 2019 09:55pm

    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.

  • Kevin Saul commented
    16 Aug, 2019 03:55am

    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?

  • Kevin Saul commented
    18 Jun, 2019 12:15am

    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.