First, I've never worked with JTS before. I _think_ it's mostly a bridge for JTA and ORBs. Second, I've used XA, but never from Java, let alone use it from within J2EE. Perhaps somebody with real experience can help you better. If I led you to believe I had experience, my apologies for wasting your time; just trying to help.
>Let's assume XA is entirely supported. How would one go about specifying the transaction context of the two threads >calling into the application server via the JTA or JCA APIs? On the previous post, you said two threads inside the app server. Now you're saying the threads are calling into; please clarify. I assume you still mean: How can I make 2 different threads _inside_ the app server participate into the same transaction? That's the point, you wouldn't be able to control that (at least declaratively). The threads would have no transactional context associated with them, you would have to carry the burden of that yourself. And then, you would have to do your own deadlock detection as well. XA and JTA(basically, a set of Java interfaces that map back to XA) allow different parties to vote in a transaction. They don't provide declarative transactions. The easiest way to implement declarative transactions when you're a Container Provider is to associate a transactional context to the App Server threads, and enroll any resource manager that is used into that thread's transactional context. The usual path is this (CMT): 1) Client calls App Server(gets a Remote or RemoteHome intf.) 2) Server creates TXAwareThread. 3) Calls proceed until a method with TX setting of REQUIRED, REQUIRES_NEW is reached. 4) Server starts a new ServerTX. 5) Server makes some notes on a central repository about the TX, such as start time. 6) Calls continue executing; whenever a resource manager is used, it's enrolled in the TX. 7) Method that spawned the TX returns. 8) The Server attempts to commit/rollback the tx. In BMT, you're in charge of 4 & 8 yourself. Asynchronously, the Central TX Repository checks if tx's execution have lasted longer than some timeout, and terminates threads(and rollbacks TX) if so. To be able to vote in an existing TX, you need to get a grip of that TX. That's called an XID in XA. You can find the corresponding java interfaces in the package javax.transaction.xa. Since BMT uses UserTransaction, and it's not specified there how to get an XID for a transaction, it depends on the App Server JTA implementation. You'd want the thread that started the tx to inform the other thread about the XID, and the second thread should get (hopefully) an instance of UserTransaction tied to that particular transaction; since you wouldn't be associating that transaction with the current thread, a lot of the facilities the Server provides automatically would be lost(one I can think of is automatic enrollment of resources into the current transaction; that works regardless of being using BMT or CMT), or, better yet, tell the app server that the thread should set its transactional context to point to the transaction whose XID you're providing. That would allow any BMT bean(even a CMT bean, perhaps) to vote in the transaction the other thread is working on. So, bottom line, it depends a lot on the App Server you've chosen. Which is a pity, since the code to make this work probably is on every app server anyway. One possible reason I can think of to leave this feature out is that it could present some security concerns(if you can actually _guess_ an existing XID, you could rollback a tx you're not supposed to know about; you could also have some access to data within the rollback segment). I don't know why you'd like to do this anyway, and I love to know the scenario here. Letting the other thread know about the XID with some guarantees of success is always a challenge in itself, so I wonder if there's not an easier way out. My 2c, HTH, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: Doug Bateman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 22, 2002 9:39 AM > To: [EMAIL PROTECTED]; Juan Pablo Lorandi > Cc: Doug Bateman > Subject: Re: 2 Threads, 1 Transaction? > > > >If the resources managers used support XA transactions, > definetly yes. > >But(probably) there goes declarative TXs, at least on one thread. > > Let's assume XA is entirely supported. How would one go > about specifying the transaction context of the two threads > calling into the application server via the JTA or JCA APIs? > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
