[
https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin....
]
Tibor Digana commented on WFLY-3852:
------------------------------------
Yes please make a reseach in the expert group.
Both annotations @Lock and @AccessTimeout were introduced in EJB 3.1, so none of them
should have higher priority.
IMHO the @AT only changes the management of thread resources. It would not change the
behavior of locks.
This means that @Lock(WRITE) will hold another concurrent Thread,
but @AT + @Lock(WRITE) does not block the concurrent thread and therefore such thread
comes back to the thread-pool and can be reused by the thread-pool to execute other async
tasks.
That's very important because without @AT the j2ee wouldn't have a way to prevent
from deadlock.
Imaging what would happen if thread-pool size is too small and all threads are waiting for
eachother - deadlock.
This happened to me with asynchronous REST client. Therefore the blocked threads can be
reused in EJB 3.1, and the @AT would do it for me.
EJB @Schedule interleaves timer calls with @AccessTimeout(0)
------------------------------------------------------------
Key: WFLY-3852
URL:
https://issues.jboss.org/browse/WFLY-3852
Project: WildFly
Issue Type: Feature Request
Components: EJB
Affects Versions: 8.1.0.Final
Environment: Win 7 x64 / i7
Reporter: Tibor Digana
Assignee: David Lloyd
Priority: Critical
Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker
skipping scheduler on concurrent Thread.
Actual:
The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls
interleave concurrently.
Expected:
The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter
which LockType is used.
According to the Javadoc
"A value of 0 means concurrent access is not permitted."
In other words the timer should give it up on concurrent Thread.
The timer should not wait for read/write lock due to the value in the annotation is not
-1.
In the internal implementation of TomEE server the timer skips scheduling if
Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not
matter.
Don't be confused with WFLY-3430.
I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with
whatever LockType. If this annotation is not used then the next call should be concurrent
/ blocked depending on READ / WRITE LockType, respectively.
My code:
@Startup
@Singleton
@Lock(READ)
public class MyTimer {
@Schedule(minute = "*", hour = "*", persistent = false, info =
"My Timer")
@AccessTimeout(0)
public void updateByMinutes() {}
}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)