OptimisticLockingListener usage


we are currently having a lot’s of OptimisticLockingException when finishing tasks.
(Which is basically valid because there sometimes happens parallel work on the same task)

The easiest way would be to just catch those errors, but I’ve now seen that the DbEntityManager tries first to “resolve” this kind of error by calling a registered OptimisticLockingListener?

It look like that it gets registered during execution of a command directly on the commandContext. Is there also some way to use this listener more “global”? Like registering job handlers at startup?

Is it in general a good idea to use such a listener for dealing with OptimisticLockingException on tasks?
My idea is to handle the OptimisticLockingException in this listener, dependent on the error.


Hi Patrick,

Can you give an example of what you would do in the listener?


Hi Torben,

if e.g. the deletion of a TaskEntity is failing, I just want to skip the throwing of a OptimisticLockingException. (Because in most cases the task was just finished already in some other transaction, and we don’t want that this causes a rollback of our transaction)

I think when the listener is used, no OptimisticLockingException is thrown, right?
So with usage of the listener we can control it a little bit more if a Exception is thrown or not.