AccessTimeout(0) changes locking behaviour in a non intuitive manner about ejb-spec

[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