[jboss-jira] [JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)

[Tibor Digana (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002209#comment-13002209 ] 

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)