Issue Details (XML | Word | Printable)

Key: EJB_SPEC-113
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: reza_rahman
Votes: 11
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
ejb-spec

Standardize Pooling and Decouple from EJB Component Model

Created: 29/Aug/13 07:23 PM   Updated: 14/Oct/13 11:24 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags:
Participants: arjan tijms, Bruno Borges and reza_rahman


 Description  « Hide

Instance pooling is currently a non-standard service provided by default to EJB @Stateless beans implicitly by most containers. As a result, although very useful for scalable, reliable mission critical systems this feature is ill understood and ill used.

This is a proposal to introduce a new annotation for the container instance pooling feature and simultaneously decoupling it from the EJB component model as a generally useful service for suitable managed beans, including CDI beans.

The programming model could look something like this:

@Pooled(minPoolSize="...", maxPoolSize="...", ...)
public class MyScalableService { ... }

This could be it's own (CDI) bean scope - which would make implementation relatively simple. However, I think it would be useful as a generic declarative service that works with various bean scopes perhaps like the following:

  • Default (dependent) scope - create bean instances, pool them and destroy them as needed.
  • @RequestScoped/@SessionScoped/@ConversationScoped/@ViewScoped - Do the life-cycle callbacks at the beginning and end of requests/sessions/conversations/views, but don't actually discard the instance and pool/reuse them instead.
  • @ApplicationScoped/@Singleton - does not make any semantic sense, but perhaps could work with something like @MaxConcurrency that's simply useful for bandwidth/concurrency throttling and not instance pooling.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.



reza_rahman added a comment - 06/Oct/13 06:10 PM - edited

One logical place for a decoupled @Pooled annotation could be Java EE concurrency utilities.


reza_rahman added a comment - 03/Oct/13 10:00 PM - edited

I'll admit the analogy is not perfect, but I was actually thinking the life-cycle would work similar to how stateless session beans work today (namely that putting something in the pool and taking it out of the pool does not trigger a life-cycle event). Alternatively, one can imagine a pooling specific life-cycle callback (similar to the activation/passivation callbacks for stateful session beans) that could be named something like @PrePool and @PostPool.

For keeping track of internal resources, one could use a technique similar to a reference count used for garbage collection (i.e. internally count the number of times one is taken in and out of the pool) - it doesn't apply to this scenario though.


arjan tijms added a comment - 03/Oct/13 09:31 PM

This is practically speaking an essential feature for retrofitting EJB as a set of CDI extensions (incidentally, I argued for the except same annotation before but didn't create an issue yet )

The combination with @RequestScoped etc may be interesting, but can also be troublesome. @PostConstruct for the @Stateless case is called when the bean is originally created. It is used among others to initialize instance variables with objects that are expensive to create (and thus greatly benefit from pooling).

In an @RequestScoped bean however @PostConstruct is called for every request. If such bean is combined with @Pooled, then I guess users would like to distinguish between those two different life-cycle events; the normal one (corresponding to the scope) at the beginning of each request and the single event when the specific instance of the bean is actually created.

A bean could track itself if it's the first call to @PostConstruct via some boolean, but for @PreDestroy this would be more difficult; how can a bean know if a specific call is the last one (in which it should maybe close some resources) or the one at the end of the request?


reza_rahman added a comment - 03/Oct/13 05:26 PM

BTW, this is an idea completely decoupled from anything JMS or JCA really.


Bruno Borges added a comment - 03/Oct/13 05:09 PM

I like the idea, but this should also support pointing to a JNDI object with configuration that could exist and be changed during runtime.

@ActivationConfigProperty is a good way to go