On 2003.02.13 08:22 Bill Burke wrote: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > David > > Jencks > > Sent: Wednesday, February 12, 2003 11:42 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] TxInterceptor split is really really good > > > > > > The design goal is to produce a working dtm that does not make > unnecesary > > inter-vm calls. The functionality of the client side tx interceptor > > appears to be unavailable with the CORBA OTS if we do not write > > some client > > side stuff. > > > > Here is the sequence of events for a call between vms where a > transaction > > is started on the client (could be a standalone app or a JBoss > instance) > > > > client starts tx > > client calls ejb proxy > > client side tx interceptor attaches tx to invocation ONLY if tx > > support for > > the method is supports, mandatory, or requires. In all other cases it > > makes sure no tx is attached to the invocation. > > invocation is routed to correct transport mechanism (such as by the HA > > Invoker interceptor)(AFAIK not yet written as an interceptor) > > Ok, its now time to split this HA stuff out....I'll work on that > now....Of > course, unfortunately, this split requires an InvocationResponse object.
Why is this unfortunate? I thought it was a great idea that is long overdue. I don't see the point in doing it 2 or three times, so I'd do it after all the interceptors are based on a common interface/model. > > > Now that we have the target jboss instance determined, the > > InvokerXAResource enlists with the tx if present, thus getting an xid > to > > transport. If no tx is present, it doesnt enlist with null. > > > > The xid is sent over the transport mechanism with the marshalled > > invocation. > > > > The server-side half of the transport mechanism/invoker extracts > > the xid if > > present, puts in in an ExcecutionContext, and uses the WorkManager > > associated with the invoker to execute the call to the ejb. The > > WorkManager communicates with the server-side tx manager to start and > end > > the transaction at the beginning and end of the call. > > > > This is all TrunkInvoker stuff, correct? Now why the reliance on > TrunkInvoker? Couldn't you just create a new Invocation object and pass > it > down the interceptor chain? I guess this would break in the current > implementation of clustering though as you say above.... Since I don't like having to reimplement the same code over and over and over again without any new ideas, I'm waiting for Jeff's remote jmx refactoring to use for all the transport mechanisms. I happened to implement the trunk invoker version before I knew about the remote jmx stuff. Consider it as a possibly unfinished example. For instance, the Work instance supplied to the WorkManager is in dire need of refactoring. I'm also not entirely sure I want to use the exact Work interfaces, in particular ExecutionContext. > > > > The method returns. > > > > At some later time, the tx commits. Since the InvokerXAResource was > > enlisted in the tx IF AND ONLY IF the tx was actually sent to do work > on > > the server jboss instance, it will get a commit call only if the server > > jboss instance actually did work in the tx. If it did work in the tx, > it > > gets (possible) prepare and commit calls with the xid for its branch, > and > > makes a invocation to call an XATerminatorContainer, which has the same > > method call syntax as an ejb container. In any case it handles > > communicating the prepare and commit calls to the server-side tx > manager. > > > > ---------------------- > > > > Of course, with optimized in-vm calls, you don't have an > InvokerXAResource > > and don't generate an xid for the method call. > > > > ---------------------- > > > > Now lets consider the alternative. Without knowing the tx > > support of every > > method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the > > InvokerXAResource, have an xid generated for it, get transmitted over > the > > transport mechansim, and enrolled in the server-side transaction > manager. > > Then when commit comes, totally useless prepare and commit calls must > be > > made to a remote vm for a transaction that COULD NOT POSSIBLY > > HAVE DONE ANY > > WORK. We have one remote call to do the requested work and up to > > two calls > > to no purpose. > > > > Ok, back to the InvocationResponse thingy we were discussing offline.... > > What is this InvokerXAResource? Is it on the client/initiating TM of a > distTrans that represents the remote TM? yes Why does an XID have to be > generated before the call to the remote TM? There's probably some way to avoid this, but it is the xa way and I think it is the simplest thing that will work. This stuff is already so complicated and understood by so few people I think following the standard model is highly advisable. Is it required that the > client > TM generate the Xid that the server must use? Only if you want anyone else ever at any time to be able to understand the system. If you want to write it, prove that it works, and be the sole maintainer, go ahead. XA model: each time (roughly speaking, ignoring connection management issues) the application makes a call to a resource manager, such as a database or another app server, the current (client) system enlists an XAResource with the current transaction. The current transaction/tm then calls xares.start(xid, flags) with an xid the resource manager is supposed to use to internally identify the transaction and the work done in it. Sometime later, when the transaction completes, the client side transaction/tm refers to the list of XAResources it maintained as enlist was called on it, and initiates transaction completetion on each of those XAResources using the same xids it provided when it called start and end earlier. If you don't want to follow this fairly straightforward model of actually using the xids to identify branches of a transaction, you have to provide some other way of converting a Transaction object into a serializable tx identifier, using the deserialized transaction identifier to start or resume a transaction branch on the remote transaction manager, and mapping the xids provided by the client tm to the alternate serializable representation of the same information so the correct info can be sent to the server tm on transaction completion. While using alternate tx ids is necessary with some databases such as Firebird that support 2pc but not using the xa id format, it doesn't make sense to me for a remote jta tm since we have to support transaction import baseed on xids anyway for the jca 1.5 spec. I do not think it advisable to treat databases and other external resource managers differently from remote jboss servers by importing the transaction by subterfuge and then only enlisting the remote server after the call returns if it turns out to have been necessary. If I had to maintain such a system the first thing I would do is rewrite it to what I have already written. > > Why can't the client side insert a boolean flag(or the client Xid?) in > the > Invocation object to let the remote TM know that it belongs in a > distTrans. > On the server side, an interceptor reads this boolen flag(Xid), starts a > transaction, associates the new TX with the current thread. The server > generates an XID and stuffs it in the InvocationResponse object. On > method > completion, the client receives the InvocationResposne object, extracts > the > Xid from the InvocationResponse, and finally does the XA enlisting. If > there is no Xid in the InvocationResponse object, the client doesn't have > to > do any enlisting. Is there a reason the enlisting needs to happen before > the method call executes? I don't want to support two completely separate ways of importing transactions. jca 1.5 requires us to support xid-based import. Why not use it? At this point I don't see any fatal problems with enlisting after all the work is done, but I would rather not try to prove it works. It seems to me that it introduces a lot of unnecessary complexity. Or is it required that the client TM generate > the Xid? yes Another conceptual problem to me in the idea of always sending the transaction and only enlisting the remote tm if the transaction needed to be sent is that the server side interceptor stack then has to deal with transport layer issues, namely interpreting the transaction representation in the invocation object and getting the tm to import it if necessary. This is IMO extremely inappropriate. The server side interceptor stack should do exactly the same things whether the call came locally or remotely. AFAICT the only way to avoid this blurring of responsibility is to only send the tx if it is needed, exactly the current implementation. > > > > It may seem unlikely that a small client would start a user > > transaction and > > then call an ejb method that didn't use it, but it seems considerably > less > > implausible to me that a jboss server would call, within a transaction, > a > > remote ejb with a non-transactional method. > > > > I'm not sure what you're saying here. Are you saying these scenarios > won't > work in your current scheme? They work fine. I'm trying to counter the argument someone might make "who would make a non-transaction call within a transaction?". david > > > > > Looking at the OTS 1.2 spec, I notice that they do not use xids > > to identify > > branches. The tx support model appears to only support the equivalent > of > > never, supports, and mandatory. Therefore, if a tx is present in an > > invocation, either an exception will be thrown or it will be used. > > Although no xid can be supplied by the OTS, jboss will still be > > responsible > > for calling coordinator.register_resource(jboss-resource) back in > > the corba > > client. I have no idea how the remote part of corba works, but it > would > > obviously be advantageous to have something analogous to the > > InvokerXAResource in the client making this call rather than requiring > a > > call back from jboss. > > > > david jencks > > > > On 2003.02.12 16:31 Bill Burke wrote: > > > What if you don't have java on the client side? What if you're CORBA > > > with > > > OTS? You're making it harder for Non-JBoss/Java clients to > integrated > > > with > > > us. I think this split should be undone. > > > > > > BTW, why the split besides code readability? Is the DTM dependent on > > > this > > > at all? Is the TM even accessed on the client side? > > > > > > Another problem I see is that the TxMethod map is required on the > client > > > side as well. Makes proxies even more heavy and what do you do about > a > > > hot > > > deploy? > > > > > > Seems to me this is a bad idea. > > > > > > Bill > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
