1

I have implemented a circuit breaker pattern in my java EE application and since it holds a state(how many failed requests, average response time, locked/unlocked and so on) I've set inte to be @Stateful. And to avoid having issues with it being serialized because of container locking I've added @ConcurrencyManagement(ConcurrencyManagementType.BEAN) and made sure that all operations are thread safe.

So it currently looks like this:

@Stateful
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class CatalogBreaker extends Breaker {

but I am still getting.

Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on CatalogBreaker - could not obtain lock within 5000 MILLISECONDS

But if I understand everything correctly the CuncurrencyManagement annotation should delegate locking to the bean and not the container... and since the CatalogBreaker does not have any locks or anything of the sort, then how come I am getting this error?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
munHunger
  • 2,572
  • 5
  • 34
  • 63
  • 4
    Take a look at the Javadoc for the ConcurrencyManagement annotation. Looks like if it's applied to a stateful bean you can't use ConcurrencyManagementType.BEAN. – Nick Wilson Feb 02 '18 at 10:23
  • Yeah, I just noticed that. However I am still getting a massive performance loss(which is probably unrelated to this issue) even though the functions called are very basic and should be quite fast – munHunger Feb 02 '18 at 10:31

1 Answers1

0

As far as I'm aware, Stateful EJBs are always locked by write locks, but I'm having some trouble finding any official Oracle documentation stating this (hence the language :'As far as I'm aware').

In other words, the annotation @ConcurrencyManagement(ConcurrencyManagementType.BEAN) does nothing. Each call to the same instance of a business method of a Stateful EJB will block the next, whereby no two business methods of the Stateful EJB can be executing concurrently.

If you have multiple threads trying to access a Stateful EJB concurrently, the container will stop them from doing so, which explains your performance loss.

The timeout, by default is 5 seconds, which is also indicated in your logs as still the default value. You can adjust the value with AccessTimeout, but I believe most would consider it bad practice to do so. I think most would agree if you're hitting that timeout, then you need to rethink your design. The reason that default is 5 seconds is because the container expects all work to be short lived tasks. You are hitting the timeout, not because your work taking too long, but because you're using a Stateful EJB in a way that doesn't comply with the way the container expects you to use it. Not to say it's wrong the way you're doing it literally, just not right...kind of like the container saying in it's dad voice: I'm not mad, just disappointed.

searchengine27
  • 1,449
  • 11
  • 26