Hi Subramanian,
Again, all valid and good questions.
>
>Hi referring to my previous mail on Testing transaction features:
>
>The user guide states that the Generic JMS RA supports XA for inbound
>communication.
>"Distributed Transactions
> Supports XA for both inbound and outbound communication."
>
>With reference to this I wanted to explain the Use case 2 described
>below clearly:
>
>The Tibco JMS Server sends a message to the MDB Endpoint in a
>Transactional context Tibco JMS Server (XID) ==>
>Generic JMS RA ==>
>MDB Endpoints
>--> Database operation that fails. (roll back) So the message ideally
>now should be redelivered.
>
>
+ the MDB should throw a runtime exception. Message redelivery
from the adapter is required only if the MDB
>You had answered that message redelivery is supported in the above case.
>
>I wanted to know whether there is a Inflow of Transactions (Chapter 14
>of JCA 1.5 Specifications) in this case.
>I had some doubts regarding this as I had examined parts of the Resource
>Adapter (GenericJMS RA) source code and whenever there is a submit Work
>call through scheduleWork(Work ..) etc. through the WorkManager no
>ExecutionContext object is passed with a set XID.
>
>For eg. In the InboundJmsResource.java there is a schedule work call:
> wm.scheduleWork(w);
>
>If this is a case of Inflow of transactions a valid execution context
>should have been passed with a set XID using the following method
>signature:
>
>void scheduleWork(Work work, long startTimeout,
>ExecutionContext ctx, WorkListener lsnr)
>
>
There are two concepts, one is message inflow and the other
is transaction inflow. Unless EIS want to pass execution context (XID)
of its transaction to appserver, scheduleWork is not required.
Message inflow happens in the XID created by appserver. The
XID is passed to the adapter (to the XAResource object) by
appserver. Look at epf.createEndpoint method in the connector API.
>Is there any difference in my understanding? Please do let me know.
>
>
The code you should probably look at is DeliveryHelper.
thanks,
Binod.
>Thanks and Regards
>Subramanian Easwaran
>
>
>________________________________
>
>Subramanian Easwaran
>+65 - 6725 6850
>Borland Singapore Pte. Ltd.
>
>-----Original Message-----
>From: Binod.Pg_at_Sun.COM [mailto:Binod.Pg_at_Sun.COM]
>Sent: Tuesday, January 17, 2006 10:48 AM
>To: users_at_genericjmsra.dev.java.net
>Subject: Re: Testing Transaction Features
>
>Hi Subrahmanian,
>
>
>
>>Hi all
>>
>>I currently have the following use-cases for testing the inbound
>>communication with Transactions:
>>
>>*USE CASE 1:*
>>Tibco JMS Server --> Generic JMS RA --> MDB End points in AppServer
>>
>>I am testing whether multiple messages can be sent as part of the Same
>>
>>
>
>
>
>>transaction (same XID). I am currently exploring the Transaction
>>support and the configurations in Generic JMS RA. If any one has tried
>>
>>
>
>
>
>>a similar use-case it would be great if you could share any
>>
>>
>information.
>
>Let me understand what you mean...
>
>The feature you are exploring is about taking one MDB instance from
>appserver and passing multiple messages to it under one transaction.
>Is that correct? I think such a capability is not supported at present.
>
>If appserver supports MDB instance pooling, then, multiple messages will
>be delivered concurrently to different MDB instances under different
>transactions. That is supported. We thought, this will cover most of
>customer needs.
>
>
>
>>
>>*USE CASE 2:*
>>The Tibco JMS Server sends a message to the MDB Endpoint in a
>>Transactional context Tibco JMS Server ==> Generic JMS RA ==> MDB
>>Endpoints --> Database operation that fails. (roll back) So the
>>message ideally now should be redelivered.
>>**
>>It would be helpful if anyone has info on import transactions using
>>Generic JMS RA and whether such use cases are possible?
>>
>>
>
>Message redelivery is supported.
>
>- Binod.
>
>
>
>>
>>cheers
>>
>>----------------------------------------------------------------------
>>--
>>*Subramanian Easwaran*
>>Borland Software Corporation
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
>For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>
>
>