On 11/11/2011 14:49, Rüdiger zu Dohna wrote:
>
> How about:
>
> NewConnection connection = connectionFactory.open(false); // this is for sending only!
> NewConsumer consumer = connection.createConsumer(Session.AUTO_ACKNOWLEDGE, // this is for receiving only!
> queue1, messageSelector, ...);
> Message incoming = consumer.receive(timeout);
> TextMessage outgoing = connection.createTextMessage(payload);
> connection.send(outgoing, queue2, ...);
That looks much like I proposed, but you're passing in the acknowledgement mode in the call to createConsumer().
Unfortunately under the existing API acknowledgement mode is tied to the session, so you couldn't have multiple
consumers with different ackModes on the same session.
(I presume we're still discussing Clebert's use case when the receive and send need to use the same session).
What's the argument to connectionFactory.open(false)? The transacted mode? I agree that this isn't needed in a Java EE
transaction (neither is ackMode). I suggest we take it as read that we would apply the simplifications we discussed for
JMS_SPEC-45 to whatever new API we designed.
>
>
> And this is not limited to the Java EE case, is it? If there is a JTA around, you'd call "open" without the
> "transacted" boolean and "createConsumer" without the acknowledgement mode. Without it, you'd have to manage
> transactions by hand, as in the code above, which is easy, since it's all one connection, right?
>
>
The problem with the non-Java EE case is that by forcing one session per connection we would be introducing a
significant restriction to the API compared with what we have now. Perhaps that's a restriction we're prepared to
impose, but I hadn't taken that step so far. Do you (both) think we should?
If we did also support the Java SE case, we would also support async delivery to a MessageListener, which wouldn't need
a separate consumer object. We could rename NewConsumer to SyncConsumer to reflect this.
Nigel