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
