MaxConcurrency annotation

[smillidge]

Annotation to define max concurrency for access to a method or bean. This was first mooted on the EJB spec but adding to concurrency would mean this could be used generally across the platform.

See javaee/ejb-spec#9

Also see https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2.1/apidocs/org/eclipse/microprofile/faulttolerance/Bulkhead.html

[smillidge]

If we have the new Async annotation I think we can have a very simple definition with just a single attribute for maxConcurrency and rely on Semaphore isolation. As the new Async annotation allows the developer to specify the specific ExecutorService which can be configured to have a maxAsync. Thread isolation can be acheived using the Async annotation and a ExecutorService with a configured maxAsync

[edburns]

Any word on getting this in for EE 11?

[smillidge]

it's tagged as a candidate for 3.1 which is the Jakarta EE 11 release. I don't think any work has been done yet though.

[njr-11]

It seems like the most important part of this is already covered by Asynchronous/executor with maxAsync, and all that remains is semaphore isolation. I am wondering what the value is of providing a @MaxConcurrency to enforce sempahore isolation when a user can already do that with java.util.concurrent.Sempahore and other classes of java.util.concurrent. How much benefit does the user get from having the Jakarta EE product provider hold onto the semaphore for them and automatically invoke it upon entry and exit from methods of a class? Is there more to this that I am not aware of?

[m-reza-rahman]

To remind of the original reason I proposed this, I don't think this should be coupled with @async, which is a totally separate use case (I think the same mistake/misunderstanding happened with @schedule). Even if it works functionally, the semantics are very confusing.

The original intent was for a way to provide an equivalent to how EJB pooling effectively causes bandwidth throttling at the component level. This should be applicable to any CDI bean that can be concurrently accessed. This is an important missing piece for EJB users that see this type of functionality as valuable. Here are the two original code examples provided:

• @Service CDI Stereotype to Replace EJB @Stateless platform#1014
• Annotation-Based API for Consuming Messages messaging#243 (comment)

[rokon12]

I believe this could be highly beneficial for virtual threads. Since virtual threads can be created in virtually unlimited numbers, we often need a way to throttle them, such as using a semaphore. In this context, having an @maxConcurrency annotation would be particularly useful.

[AngeloRubens]

I also think it's important to have this feature, you can see this first sample RI for CDI context https://github.com/omnifaces/omniservices....

regards

[lprimak]

Big +1 for @Service Annotation. I would think that @Service(maxConcurrency = 10) would be great without a separate annotation. Default being what's configured by the platform

[m-reza-rahman]

There are two reasons for aiming for a separate annotation. The primary one is treating this as a cross-cutting concurrency feature that can be applied to a variety of CDI components as users wish. Also, as far as I am aware, stereotypes themselves are not bound to interceptors directly and typically do not have attributes defined.

I can see this, however, as an attribute of @Lock or something that works with @Lock.