Thanks for having a look at this issue, Christian. The example above uses optimistic locking according to e1.getLockMode(foo1). This seems to be the default? This is also the lock mode I got in Wildfly when I originally discovered the problem. I wasn’t aware you can run hibernate without transaction management / locking.

I’m totally not an expert on this, but from my current point of view the lock mode operates on a per table row basis. This would not be sufficient to protect against this kind of problem. The root of the problem is that hibernate only updates the indices of the list elements it thinks have changed. This is what effectively prevents locking from kicking in here because the other table rows never get touched but have to be considered to keep the indices sane. It should take into account that other indices might have changed in the meantime.