AccessTimeout(0) changes locking behaviour in a non intuitive manner

[glassfishrobot]

According to the spec:

"An AccessTimeout value of 0 indicates that concurrent access is not allowed."

This seems really odd to me, as if you has a READ lock on a method that basically says that concurrent access is allowed, however then adding an AccessTimeout(0) to that method prohibits concurrent access, and then basically turns it into a WRITE lock.

I would have thought that the intention was just that if the lock could not be acquired immediately then a ConcurrentAccessException should be thrown, I would not expect this to change the underlying behaviour of the lock.

[glassfishrobot]

Reported by stuartdouglas

[glassfishrobot]

@ldemichiel said: The EJB 3.1 Expert Group made the decision to assign this semantics to AccessTimeout(0) instead of introducing something like a ConcurrencyManagementType.CONCURRENCY_NOT_ALLOWED value. I think this annotation is mostly useful to override for a method behavior that is specified at class level.

[glassfishrobot]

@ldemichiel said: Not a bug

[glassfishrobot]

stuartdouglas said: There is already a way to do that though (@Lock(WRITE) @AccessTimeout(0)). It seems really silly that if you do @Lock(READ) @AccessTimeout(0) two threads cannot call the method at the same time, even though @Lock(READ) explicitly allows this behaviour.

This basically has the effect of transparently turning a READ lock into a WRITE lock, for no good reason (if the user wanted a write lock they would have use @Lock(WRITE)).

[glassfishrobot]

@ldemichiel said: Combining the two annotations doesn't make a lot of sense to me. I think the intention was to treat AccessTimeout as an override over any concurrency. That is different from turning a READ lock into a WRITE lock, because there is no waiting involved for the lock to free up – instead one just gets the ConcurrentAccessException. BTW, I'm certainly not disagreeing with your general point about lack of intuitiveness in the design though.

[glassfishrobot]

stuartdouglas said: I think it makes sense. Intuitively AccessTimeout(0) means 'I don't want this thread to block, if you can't get the lock straight away throw an exception', so if it is applied to a read lock I would expect that if another thread holds the write lock an exception will be thrown, otherwise the thread would proceed as normal.

With the current wording there can be situations where the current thread can take the lock immediately (as there are only other read threads active), however it still has to throw an exception because of the 'no concurrency' stipulation.

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-122

[glassfishrobot]

Marked as works as designed on Monday, September 15th 2014, 1:54:49 pm