On 10/11/2011 17:54, Clebert Suconic wrote:
> On Nov 10, 2011, at 9:51 AM, "Rüdiger zu Dohna"<ruediger.dohna_at_1und1.de> wrote:
>
>> On 10.11.2011, at 16:31, Clebert Suconic wrote:
>>> I guess I'm proposing merging connection, session and producer altogether. And connection, session and consumer.
>>
>> Maybe I'm oversimplifying. The simple case is, as you suggest:
>>
>> NewConsumer consumer = connectionFactory.createConsumer(...);
>> NewProducer producer = connectionFactory.createProducer(...);
>>
>> With two "contexts".
>>
>> But what should these contexts share? I think only the transaction, isn't it? And that's standard JTA:
> If you have one around those two calls, they share it (which doesn't necessarily mean it's XA),
> and if you don't have one, they use separate transactions.
>
> Anything as long it won't require a client to perform 4 round trips
> calls to server. Two prepares. Two commits.
>
> I'm not sure how we could do it with simple JTA.. I guess I need to
> read that spec. If anyone has an hypothetical example?
>
> We need to keep the usage simple for that case as well.
In Java EE, if you want to be able to synchronously consume a message and then send a message in the same transaction,
without the need for two-phase commit, then there are two ways to achieve this:
(1) both consumer and producer use the SAME old-style session underneath. That will ensure that only a single XAResource
is enlisted with the transaction manager. The transaction manager would see that there was only one XAResource in the
transaction and perform a one-phase commit.
(b) (take a deep breath...) both consumer and producer use DIFFERENT old-style sessions (and hence connections)
underneath. This will cause two XAResource objects to be enlisted with the transaction manager. This would normally
cause a two-phase commit. However if the JMS server is capable of performing a JOIN operation on the second XAResource
to the same transaction branch as the first XAResource, and it signifies this by returning
xaResource1.isSameRM(xaResource2) to be true, then the TM will perform a single-phase commit. I suspect most JMS
providers support this now, but it is not mandatory and it would be best for the spec not to rely on it.
Nigel