Write to datastore generates no errors on incorrect @version attempt

Hello Rich,

I am not sure what is exactly your issue? Can you please share more details on your use case? Why you picked the optimistic locking and what is the final goal.

The problem is On the function or the process model? Are you maybe calling the process with startProcess function or something like that ?

Can you please share more details,

- On which version you are?

- How are you adding the locking on the cdt? maybe just share ele element of the cdt/Xsd

- are you expecting the actual error message ? Or you want to know there was an error?

- have too taken a look to the logs and check if there was an error message ?

The documention of that function does give you the onError Option for that function. Please refer to the docs,

It is mentioned like “onError (Any Type): A list of saves or an HTTP response to execute when the smart service does not execute successfully. Created with a!save() or a!httpResponse().”

In case of the process model, well if it fails to insert the process will stop with error, and you will be able to see the error on the node on the “error” tab.  So if you need to take action if any of this situations happens, maybe you will need to check the value or change the application to avoid that scenario.

Hope this helps

Jose

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>