On 2003.02.13 10:35 Bill Burke wrote: > > > > > > > > > > > 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. > > Yes, its long overdue. I'm doing it now....By "unfortunate" I meant, > this > is a pain in the ass to do since it affects a lot of code and a lot of > code > must be retested. > > I DO see a point in doing it 2 or 3 times. Its easier to debug if > problems > come up. Since I know the current invocation architecture works for the > most part I first port the InvocationResponse there. When that works, I > know I have a good foundation to do the new interceptor(AOP) and invokers > changes. Well that's the way I like to do things....
I like small testable refactorings also:-). I just don't see the point in adapting this stuff to one set of interfaces, then next week adapting the same code to another set of interfaces. I have one more or less working example (trunk invoker) and think I will make fewer mistakes porting if I only do it once to the future jmx transport stuff. BTW I strongly encourage you to use the module level testing framework I put in to do real unit tests on these components rather than the typical integration type tests we usually write. I found it a really big help working on the dom4j refactoring. > > > > > > > > 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. > > I don't think you should be using any of the TrunkInvoker or WorkManager > specifics to do TM communication. If you have some sort of TxInterceptor > that handles all this Xid stuff, then there's no reason you can't create > a > temporary new Invocation object that will be passed along the same > interceptor chain and invoked on the remote TM, or be able to extract the > information you need to do remote TM communication from the current > Invocation object. Even without Jeff's refactor, shouldn't you be able > to > do this? That's what I try to do right now. In particular, prepare/commit etc calls use the same transport mechanism and target-finding approach as ejb calls: they go to a XATerminatorContainer which looks like an ejb container but talks to the TM. The client side stuff (InvokerXAResource) is already completely generic (I think). The server side stuff is still quite mixed up in the trunk invoker specifics. If Jeffs jmx stuff doesn't arrive soon I will probably refactor that to make it more reasonable. > > > > > > > > > > > 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. > > > > I'm sorry for being confrontational with the email subject of > "TxInterceptor > split is bad", but it got your attention didn't it? If you're going to > make > such a significant change to the core of our codebase you're going to > have > to explain your reasoning (which you have) and listen to and argue > against > alternative ideas. This is core stuff David, so don't take it > personally. > We all need to understand what is going so that we can help maintain this > stuff and because it may affect the current work we are doing. Tom and > Jeff > are going to go through the same pain. > > > > 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 > > Ok. Didn't know that this was a generalized common pattern. > > > 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. > > > This is great stuff David, I will capture this on the forums for > historical > and referencial purposes. David, this whole email thread needed to > happen. > Yes, I was being abrasive somewhat, but I did it to get your attention. > Sometimes questions get ignored if you're nice.... Well, I guess if you don't mind me writing a few mails in which I am trying to prove you are an idiot:-)) I don't mind either. david > > Bill > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
