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

[Tibor Digana (JIRA)]

Tibor Digana created WFLY-3852:
----------------------------------

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