[JMS_SPEC-143] Define standard MDB activation properties to allow the MDB pool to be configured Created: 20/Nov/13  Updated: 20/Nov/13

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

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms21-forreview-minor

 Description   

Should there be standard activation properties to allow the pool of MDB instances to be configured?

It's not clear whether this is desirable or not.

MDBs are defined in the EJB specification, not the JMS specification, so we would need to work with the EJB expert group on this.

MDBs aren't just for JMS, so we would need to consider is whether we'd want to define standard pooling properties just for JMS, or for all MDBs.

The EJB spec doesn't require a MDB (whether JMS or not) to be implemented using a pool of MDB instances. So in standardising pooling we may be trespassing on what is currently an implementation detail.

Most MDB pools are configured using multiple properties such as initialPoolSize, minPoolSize, maxPoolSize, steadyPoolSize and so on, depending on how the pool is implemented and what features it offers (e.g. some pools may allow the pool to grow and shrink whilst others might be fixed-size). Which of these are could be standardised and which of these would we have to leave as an implementation detail? It would probably be inappropriate to attempt to standardise them all.

On the other hand, the new Java EE 7 resource configuration features do introduce a notion of pooling for JMS connections (not MDBs). The new <jms-connection-factory> deployment descriptor element has the sub-elements <max-pool-size> and <min-pool-size>, and the new javax.jms.ConnectionFactoryDefinition annotation has the attributes minPoolSize and maxPoolSize. So this does offer precedent for defining pooling properties.


Generated at Sun Jul 24 09:04:25 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.