> The current wording in the spec basically implies that @AccessTimeout(0) turns a READ lock into a WRITE lock

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() {} }