| [cu-dev] Should the Concurrency specification introduce a way for applications to access named semaphores in a Jakarta EE application? |
In the past, I have seen named semaphores as a way to ensure that an EE
application can meet expected service level agreements (for both
clustered + non-clustered deployments). Would the Concurrency
Specification be the right place to introduce named semaphores?
A high level example would be something like:
Configure a set of named semaphores in an application that are associated with certain EE container threads. Each defined semaphore would have a name and a number of permits.
As part of the app design/development process, identify
application operations that are CPU expensive so that a smaller
number of permits would be used. Think of an administrative UI
operation that has to access all rows in a database table that could be fast for a small number of rows but very expensive for a large number of rows. Perhaps
the number of permits would be really low like 1-5 to throttle
the number of administrators that could access that very expensive part of the application at the same time. For less expensive operations, the number of permits could be much higher.
Additional changes would be needed to be scoped out to make use of named semaphores in various EE containers that could benefit from them.
An alternative could be to introduce named semaphores at the Java SE level via the java.util.concurrent.Semaphore class which could also be made use of by various EE containers.
Suggestions?
Thanks,
Scott