optimistic LockModes

[gavinking]

The LockMode types OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT passed to lock() are used to explicitly request a version check or version increment during the before completion phase of the transaction (not at flush time, if I understand correctly).

Since we don't really even have a well-defined transaction completion phase at this stage, I'm not going to add them now.

Also I doubt these are very widely-used.

[gavinking]

Folks, please note that this issue isn’t saying that we don’t support optimistic locking! It’s a very specific issue with passing certain lock modes explicitly to the lock() method, a feature which didn’t even exist in Hibernate and JPA prior to JPA 2.

[gavinking]

So fixing this issue requires adding reactive implementations of(at least):

• DefaultPostLoadEventListener, and its helpers
• EntityVerifyVersionProcess and EntityIncrementVersionProcess, which will call ReactiveEntityPersister.lockReactive() and reactiveGetDatabaseSnapshot().

This doesn't look so bad.

[gavinking]

This is done for find() in #329, but still not for lock().

(It's also not done for refresh(), but if I'm not mistaken core doesn't support these lock modes in refresh() either, so I'm not sure I care.)

[gavinking]

Done, finally!