[EJB_SPEC-113] Standardize Pooling and Decouple from EJB Component Model Created: 29/Aug/13  Updated: 19/Jun/15

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: reza_rahman Assignee: Unassigned
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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.



 Comments   
Comment by Bruno Borges [ 03/Oct/13 ]

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

Comment by reza_rahman [ 03/Oct/13 ]

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

Comment by arjan tijms [ 03/Oct/13 ]

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?

Comment by reza_rahman [ 03/Oct/13 ]

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.

Comment by reza_rahman [ 06/Oct/13 ]

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

Comment by braghest [ 19/Jun/15 ]

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.

Generated at Mon Dec 05 19:33:21 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.