Page 1 of 1

About Question enthuware.oce-jpad.v6.2.364 :

Posted: Fri Dec 23, 2016 5:53 pm
by johnlong
If the lock cannot be obtained, an exception is thrown and the Transaction is marked for rollback.
Is marked as wrong answer
Would the answer "If the lock cannot be obtained, an exception may be thrown and the Transaction may be marked for rollback." be correct?

Re: About Question enthuware.oce-jpad.v6.2.364 :

Posted: Fri Dec 23, 2016 10:21 pm
by admin
Yes, that would be correct.

Re: About Question enthuware.oce-jpad.v6.2.364 :

Posted: Sat Jul 08, 2017 10:05 pm
by himaiMinh
Hi, everyone,
the transaction is marked for rollback only if the database locking failure results in
transaction-level rollback...; otherwise a LockTimeoutException is thrown and only the current
statement is rolled back....
How do we decide when the locking will result in transaction-level rollback and when the locking will result in statement level-rollback? Or, it is up to the developer to specify in try/catch block?
So, if the developer put

Code: Select all

catch (LockTimeoutException exception) {  // do something to rollback the statement and retry} 
?
Or, use

Code: Select all

 catch (PersistenceException exception){ ...// ejbContext.setRollbackOnly(true); // do some retry....} 

Re: About Question enthuware.oce-jpad.v6.2.364 :

Posted: Sun Sep 23, 2018 4:00 pm
by __JJ__
himaiMinh wrote:
Sat Jul 08, 2017 10:05 pm
How do we decide when the locking will result in transaction-level rollback and when the locking will result in statement level-rollback? Or, it is up to the developer to specify in try/catch block?
I believe that is dependent on the underlying database.

Re: About Question enthuware.oce-jpad.v6.2.364 :

Posted: Sun Sep 23, 2018 4:05 pm
by __JJ__
All the lock mode types are required to be supported. However, they are not required to be supported on non-versioned entities.
I think PESSIMISTIC_READ is not required to be supported; and if not supported a request for it will be upgraded to PESSIMISTIC_WRITE:

Spec:
It is permissible for an implementation to use LockModeType.PESSIMISTIC_WRITE where LockModeType.PESSIMISTIC_READ was requested, but not vice versa
ProJPA2:
Pessimistic Read Locking
Some databases support locking mechanisms to get repeatable read isolation without acquiring a write lock. A PESSIMISTIC_READ mode can be used to pessimistically achieve repeatable read semantics when no writes to the entity are expected. The fact that this kind of situation will not be encountered very often, combined with the allowance that providers have of implementing it using a pessimistic write lock, leads us to say that this mode is not one to be easily picked up and commonly used.