Write to datastore generates no errors on incorrect @version attempt

We're trying to implement record locking using @Version JPA.  Using the expression a!writetodatastoreentity() will throw an error in designer but not in the actual user interface.

There's nothing similar to even the onError: {} parameter in the process model based option.

Are there any suggestions for capturing a failure and altering the process path accordingly?

Thanks in advance

  Discussion posts and replies are publicly visible

Parents
  • Whilst using the JPA @Version is one method for implementing record locking it's not an ideal solution for the very reasons you've highlighted. If you want to lock records AND provide a meaningful User Experience then you'd be better of designing and implementing your own pessimistic record locking solution:

    • create a table to hold locks (table will hold meta data about the entity and the instance that the lock is being held against, along with who took the lock and when)
    • create a Stored Procedure that:
      • first checks if a lock is held against the entity in question. If one does then the Who/When are returned - you can then display these avlue sin the front end to the end-user
      • if there is no lock, then it takes a lock
      • when the processing is completed the lock is then removed from the locks table
      • whenever anyone wants to conduct some update processing against an entity then the process model first checks to see if the lock exists and either returns the who/when or returns a lock token

    The beauty of this is that the End User can see that a lock exists AND who took it and WHEN.

    S>

Reply
  • Whilst using the JPA @Version is one method for implementing record locking it's not an ideal solution for the very reasons you've highlighted. If you want to lock records AND provide a meaningful User Experience then you'd be better of designing and implementing your own pessimistic record locking solution:

    • create a table to hold locks (table will hold meta data about the entity and the instance that the lock is being held against, along with who took the lock and when)
    • create a Stored Procedure that:
      • first checks if a lock is held against the entity in question. If one does then the Who/When are returned - you can then display these avlue sin the front end to the end-user
      • if there is no lock, then it takes a lock
      • when the processing is completed the lock is then removed from the locks table
      • whenever anyone wants to conduct some update processing against an entity then the process model first checks to see if the lock exists and either returns the who/when or returns a lock token

    The beauty of this is that the End User can see that a lock exists AND who took it and WHEN.

    S>

Children
No Data