Standardize Pooling and Decouple from EJB Component Model

[glassfishrobot]

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.

[glassfishrobot]

Reported by reza_rahman

[glassfishrobot]

miojo said: 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

[glassfishrobot]

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

[glassfishrobot]

@arjantijms said: 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 tt>@RequestScoped</tt etc may be interesting, but can also be troublesome. tt>@PostConstruct</tt for the tt>@Stateless</tt 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 tt>@RequestScoped</tt bean however tt>@PostConstruct</tt is called for every request. If such bean is combined with tt>@Pooled</tt, 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 tt>@PostConstruct</tt via some boolean, but for tt>@PreDestroy</tt 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?

[glassfishrobot]

reza_rahman said: 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.

[glassfishrobot]

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

[glassfishrobot]

braghest said: It would be nice if there was a way to disable pooling in MDBs. It would be nice to be able to have a servlet / @Singleton concurrency model for MBDS. Currently the pool size of the MDBs limits the amount of parallel processing available for MDBs.

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-113