ISPN-11020 introduced a new implementation of clustered max idle. Due to how locking in optimistic transactions work and the fact that we try to limit the number of expiration removals for a key it can cause a deadlock. To work around this we ensure that reads use a lock acquisition timeout of 0 and catch and check the exception for a TimeoutException. Exception checking is inherently error prone as the cause/supression of exceptions can change very easily as well as the exception could be thrown for a different reason. We should convert this by possibly changing OptimisticLockingInterceptor to return something different if a lock occurs with a lock acquisition timeout of 0.