Thanks for the interesting suggestions. Could you please open a new issue in the JMS spec JIRA for this?
I'd like to clear the existing backlog of started-but-incomplete features before we consider new ones, but I don't want to lose this idea. More comments below...
(N.B. Anyone else reading this is very welcome to join in)
On 28/06/2012 06:36, Chris Barrow wrote:
Hmm. If the application is consuming messages in different threads at the same time then shouldn't it be using different sessions?
I realise this can be overcome to some degree by using multiple MessageConsumers on separate Sessions, but that imposes more of an overhead on the JMS provider. A better alternative, which is already offered by certain JMS providers (including Tibco EMS and ActiveMQ), is INDIVIDUAL_ACKNOWLEDGE mode, where acknowledging a message acknowledges only that message. This makes multithreaded or asynchronous processing of messages much easier to implement.
This sounds reasonable, but I think we would need to explore that you mean by multi-threaded processing of messages so we can be sure that the use case you have in mind can be supported without breaking the threading restrictions on a session.
Over in Java EE, where messages from a destination are being processed by a pool of MDB instances, then we do have multi-threaded processing of messages. If the MDB is configured to use container-managed transactions then a transaction commit covers an individual message only, which sounds a bit like what you have in mind. Interestingly, though, the EJB spec doesn't allow client acknowledgement in MDBs. I wonder why.
[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes