Ole, Thanks for all your help - I am beginning to see a clearer picture now.
Unfortunately, the way most people are currently running JBoss is with paired in-vm web/ejb containers accessing (I assume) the same DB - a homogenous cluster in which all nodes are configured identically. This means that transactions would have to move from ejbcontainer to ejbcontainer, which we have concluded is non-trivial. I shall bear in mind that moving a transaction between webcontainers sharing a common ejbcontainer is a much simpler task. The spec does not make this mandatory, but suggests that many vendors will implement this, since it is important for failover between web nodes. I think that as JBoss grows in popularity we will see more call for heterogeneous clusters with specialist web and ejb nodes. When this happens the need to be able to fail-over between web nodes and pass a UserTransaction will become more pressing. So, in conclusion, there is no urgency, but it is a feature that I think we should have at some point in the not-too-distant future. So, if it interests you I would be grateful to have it, otherwise just file it away mentally for your next iteration over your code..... Thanks for making this an interesting thread - I've learnt a lot. Jules Ole Husgaard wrote: > Jules Gosnell wrote: > >>THIS WILL NEED A FIXED FONT... >> >>with regards to your question about from where the UT is obtained. >> >>The UserTransaction would be created in a webapplication running in a >>webcontainer. >> >>I have many possible scenarios for arrangement of web, ejb and db tiers :-( >> >>The most complex is : >> >>N* webcontainer --> 1*ejbcontainer >>N* ejbcontainer --> 1*database >> >>i.e. >> >>db >>| >>------------------- >>| | >>ejb ejb >>| | >>---------------- ---------------- >>| | | | | | >>web web web web web web > > > In this configuration, an UT might be moved from one > webcontainer to another webcontainer accessing the same > ejbcontainer, but not to a webcontainer accessing > another ejbcontainer. Problem is that the active > transaction only exists in the VM of one of the > ejbcontainers. > > >>web, ejb and db tiers could all be remote to each other, OR sharing vms, >> I need to be able to support any configuration. > > > It does not matter if the db and ejb tiers are in the > same VM, since xa handles both nicely. > > But there is a difference if the ejb and web tiers are > in the same VM: If in the same VM, the UT implementation > is org.jboss.tm.usertx.client.ServerVMClientUserTransaction. > If in different VMs, UT implementation > org.jboss.tm.usertx.client.ClientUserTransaction is used. > > >>The most usual config might be : >> >>1*webcontainer --> 1*ejbcontainer --> 1* database (web & ejb tiers in >>one vm) >> >>i.e. a JBoss with integrated web and ejbcontainer..... (db--ejb--web) > > > This is trivial, but you probably don't need to > move an active transaction from one container > to a fail-over container in this case ;-) > > >>I'm simply writing the infrastructure, so I have no control over the >>topology of the systems in which it will be used :-( >> >> From your answer it looks as if this is possible, provided that the >>webtier ALL SHARE the same ejbcontainer ??? > > > Yes. > Also if transactional fail-over only happens with > webcontainers accessing the same ejbcontainer. > > >>but if there are multiple >>ejbcontainers all sharing the same database it would not be possible ? > > > It might be possible. I'm not sure, since I don't > know how clustering handles transactions. > However, I would guess that an active transaction > only exists in the TM residing in the VM of a single > ejbcontainer, and if this is unavailable (when > fail-over is needed), we cannot get to that > transaction. > > One workaround for this might be to use a transaction > service that supports distributing transactions > between VMs. Tyrex supports this and works fine with > JBoss, thanks to Anatoly Akkerman. Each webcontainer > could then have its own transaction service running, > and transactions would be automagically distributed > to the ejbcontainers using the normal transaction > distribution methods (instead of the rather limited > client UT transaction distribution methods). > If your webcontainers are JBoss servers without ejb, > only running web components, this may be an option. > In this case, the transactions are actually being > controlled in the webcontainer, and transactions are > propagated with all calls to all ejbcontainers, making > fail-over to another ejbcontainer simple. > However that approach might pose a problem with fail- > over between webcontainers, since the transaction now > exists in the webcontainer. > > For completely redundant operations with no single > point of failure (not counting the db), a distributed > multi-node transaction service is needed. Such a beast > would be so hairy that I prefer not to think about it. > > >>Does this sound like a correct conclusion ? > > > Yes. > > >>so >> >>db >>| >>| >>ejb >>| >>-------------------------------- >>| | | | | >>web web web web web >> >>is OK, but the first layout is not, because the UserTransaction is only >>valid across 1 ejbcontainer.... > > > Exactly. > > >>It looks as if this is not going to fly trivially - but it is good to >>touch base and share requirements. > > > With only one ejbcontainer, adding support for moving > transactions between webcontainers wouldn't be that hard. > Probably the right way would be to: > - Create a JBossUserTransaction interface that extends the > javax.transaction.UserTransaction interface. > - Add two new methods to this interface, with semantics > similar to the javax.transaction.TransactionManager > suspend() and resume() methods. > - Unlike the TransactionManager suspend() and resume() > methods who work with javax.transaction.Transaction > instances, the JBossUserTransaction methods would > work with java.lang.Object instances that are > serializable at runtime (transaction propagation > contexts). > The message- and session-bean UT remain unchanged. > Whenever a remote or local client requests an UT, a > JBossUserTransaction would be delivered, so a > typecast could be used to get to the extended > functionality. > > If the webcontainers reside in the same VM as the > ejbcontainer, this change would be almost trivial. > > It would be a bit more tricky when in different VMs. > This is due to the RMI server object in the ejbcontainer > VM: It has been programmed to automatically roll back > active transactions when the client dies. > However a RMI server object flag to avoid that could > be set on the first call to JBossUT.suspend() or > JBossUT.resume(). That is, if one of these methods > have been called, it should be expected that another > client will take over whenever the first client dies. > > >>I'm in no hurry, but would be interested to hear if our UserTransaction >>implementation got to the point where I could support some of the above >>configurations.... > > > I could implement the above next week, if you are > interested, and if it is what you need. > > > Best Regards, > > Ole Husgaard. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > 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 Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
