Hello,

I don't see why this is rejected. This is a true issue and I don't see why you requires to have a test case for this (if it is the case of the rejection). From when Oracle prefers locking in 2 steps (this is more a bad joke for me)? This bug might lead in some inconsistencies for applications using Hibernate because - apart from the fact that we are using a useless second query just to lock the row - you are also making it in the wrong order:
1- Read data
2- Lock data
if between 1-2 a change is made on the row we will work on stale data (and might override another process's changes!!!!).

At least you have to do it in the opposite order to ensure consistency.

And please be more flexible on this test-case rule. For me it is enough to say that we are using oracle and we are getting this message. Making clean test cases can take really important time for loggers. Sometimes more than the resolution time of the bug ...