> > SwiftMQ doesn't support start(suspend), so they return false for all calls > > to isSameRM(). This should cause all connections being enlisted to be given > > a unique xid (with different branch qualifiers). I think this is compliant > > with the JTA and XA specs. > > start(suspend) doesn't make sense to me. Do you mean > end(suspend), start(resume) or start(join)?
As you guessed, I meant start(join). > So SwiftMQ doesn't support something it ought to for > JTA compliance... > And to get around that, it does something truly wierd. > > This may in some cases be heavy performance-wise, since > there may be a lot of "=="-equal resources enlisted > with the TM. I have heard that some application servers > in some cases delist before every call to another bean, > and enlist again afterwards (that way the other bean can > use the same connection, even if in another tx). > > Have you checked if this is listed as a bug in SwiftMQ? Andreas Meuller sent me this link: http://www.jguru.com/forums/view.jsp?EID=914840 Around the middle it explains that SwiftMQ returns false for all calls to isSameRM. I agree that it may well be a heavy performance hit, but I still believe it is compliant. > > Basically, we can't assume that (resource1 == resource2) implies > > (resource1.isSameRM(resource2)). > > Ouch. > > I have been assuming this, but when rereading the JTA > specification, I see nowhere that we can assume this. > > JTA really ought to explicitly state if such an > assumption can be made, or it will be a source of > implementation errors. I agree. > > The problem now is that the TM must be able to enlist the same resource > > multiple times with different branch-ids, and then figure out which xid to > > use on the next call to delist. > > Agreed. > > > I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think > > fixes the problem. Please let me know what you think. > > I just had a quick look at the 3.1 patch, and it looks > fine to me. > > I have a question though: Why also check for RS_ENDED state? > And a comment: In delist, probably an exception should not > be thrown. False should be returned instead, and IMHO the > exception at line 451 should also be changed to returning > false. This is going to take a little explaining. I make the assumption that each XAConnection has an individual XAResource. If they are using some singleton concept for XAResources, then this technique will fail. (In fact, there would be no possible way to solve this problem if that was their approach.). Assume we are working with an RM that returns false always for isSameRM, and that it has not yet been enlisted in the current tx. The first enlistResource(rm) is trivial. After, one of two things can happen: delist(rm, success/fail) // rm status is RS_ENDED delist(rm, suspend) // rm status is RS_SUSPENDED (Note: it can't be enlisted yet, since the connection is not available to the free pool). In both cases, the connection is returned to the pool. Now someone can get that resource again, and enlists it in the same transaction. If it was ended with success/fail, then the original tx is ended, and a new one needs to be started. If it was suspended, then we need to resume. So we could be left with one of the follow: resourceState table (if first delist was success/fail): rm - ended rm - enlisted resourceState table (if first delist was suspend) rm - enlisted Continuing, the resourceState table would always look like: rm - ended rm - ended ... rm - ended rm - enlisted / suspended i.e. any number of ended states, possibly followed by a single state that is either enlisted or suspended. So, finally answering your question, the checks for RS_ENDED allow the search to skip over all the ended states, and get to the last one, if it exists. > > But still I wonder: What happens if several SwiftMQ > "=="-equal resources are enlisted in the same transaction. > How do we ensure that it is the right resource that we call > end() on? After all, we do not get the Xid supplied to the > delist call, so we really have no way of knowing which Xid > to end when the resources are "=="-equal. Hopefully my explanation above explained it. If not, let me know and I will try again. -Larry ------------------------------------------------------- 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
