On Mon, 2007-03-26 at 17:46 +0100, Rupert Smith wrote: > Are you planning on using the interfaces already provided in > javax.transaction.xa? I noticed that your TransactionManager interface > is very close to XAResource and your Xid interface is identical to the > one in that package. Is this stuff working at a lower level or is it > intended to be a JTA implementation that works in the standard way > with java transaction managers?
The plan is to provide XA support i.e. we will implement an XA Resource on the client side and most certainly a JMS XAConnection and corresponding XASession. AMPQ defines the dtx classes for providing XA support this is why on the server, the TM API is similar to the XA one you are familiar with. > The reason I ask, is I'm trying to imagine writing a JCA resource > adapter to plug Qpid into an app server. To do this you have to > implement XAResource in javax.transaction.xa. We will need to implement JMS XAConnection, XASession and XAResource and ConnectionConsumer for plugging our JMS implementation in an App server. This is the case when we want to use JMS but I don't think we should try to plug Qpid within an App server using a resource adapter. > Also, what about the case for non-XA (local only) transactions. The > transactional enqueue and dequeue methods must take Xid parameters. In > the local case would you just generate some suitable values to use for > these or would the local transaction methods on MessageStore be > different or just like they currently are? We will use the same methods, the only difference would be that the API caller would need to create an Xid for referencing a local tx. So, there isn't a real difference between a local tx and a distributed one. The only thing is that local transactions always use one phase commit. So you would do something like: xid = Xid.create() TM.begin(xid) PS.enqueue(xid, M) TM.commit-one-phase(xid)
