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

Moderator: admin

Post Reply
johnlong
Posts: 197
Joined: Mon Jun 20, 2016 5:06 pm
Contact:

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

Post 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?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

Yes, that would be correct.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

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

Post 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....} 

__JJ__
Posts: 125
Joined: Thu Jul 05, 2018 6:44 pm
Contact:

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

Post 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.

__JJ__
Posts: 125
Joined: Thu Jul 05, 2018 6:44 pm
Contact:

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

Post 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.

Post Reply

Who is online

Users browsing this forum: No registered users and 29 guests