[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=13002139#comment-13002139 ] 

Tibor Digana commented on WFLY-3852:
------------------------------------

Hi Stuart,

The @AccessTimeout(0) is an exceptional status in the behavior of Write/Read lock, where 0 does not mean timeout.
The Javadoc in annotation AccessTimeout does not say anything about any lock.
This means that @AccessTimeout(0) != (Read or Write) lock.
Here the point is that the timer's method should not be called if some other thread is currently in it.

>> The current wording in the spec basically implies that @AccessTimeout(0) turns a READ lock into a WRITE lock
If you do it like that, then it's another bug. The idea behind @AccessTimeout(0) is different. No need to interchange the locks.
The @AccessTimeout(0) is not supposed to set concurrent Thread to BLOCKED status in Write lock.
Simply just use tryLock() method instead of lock() if @AccessTimeout(0) is used on the timer's method.
That's all we need to do.
When you observe false from tryLock(), then you should ignore calling timer's method because other thread is currently executing it; Otherwise (returned true) you have observed lock pretty much like with the lock() method on ReentrantReadWriteLock.



> 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)