Can Hibernate implement pessimistic locking at the start of a Java transaction, or does it instead rely on a pessimistic lock being applied when all the work in the Java realm is done, and then the changes are applied to the database as part of a database transaction?
I ask as I've got a Java transaction, halfway through which a call to a remote web service is made, which is non-transactional and thus cannot be rolled back. If Hibernate holds a pessimistic lock on the data being acted upon, then the processing of the transaction should be blocked as Hibernate knows another thread is already acting upon those data. If Hibernate doesn't keep a track of such locks itself, then the Java transaction will continue, invoking the webservice, and then blocking on the DB commit.
What I really want to happen is for the Java transaction to start, another thread attempt to start another transaction, and block/fail because there's already one in progress for the relevant data.
How is the locking behaviour affected when Hibernate's using EHCache as a 2LC in a distributed fashion with Terracotta?
Hibernate pessimistic locks are database locks. The locking is delegated to the database. The second-level cache has nothing to do with it.