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 etc.... web, ejb and db tiers could all be remote to each other, OR sharing vms, I need to be able to support any configuration. 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) 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 ??? but if there are multiple ejbcontainers all sharing the same database it would not be possible ? Does this sound like a correct conclusion ? 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.... It looks as if this is not going to fly trivially - but it is good to touch base and share requirements. 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.... Thanks for your time, Jules Ole Husgaard wrote: > Jules Gosnell wrote: > >>Ole, >> >>HttpSessions are used for storing conversational state, between browser >>requests, in the web tier. >> >>One of the purposes of DISTRIBUTABLE HttpSessions is fail-over. e.g. You >> (the browser) are having a conversation with a JBoss node, walking >>through a questionnaire. The node that you are talking to fails and you >>are directed to another working node. My job is to make sure that when >>your next request arrives at that new node, your conversational state is >>available so the that webapplication can seamlessly reprise the >>conversation. i.e. you can continue with your questionnaire, unaware >>that you are now talking to another machine. > > > I'm not at all familiar with clustering, fail-over and > nodes. > > Just in case some of this might block what you want: > > The UserTransaction implementation for clients in > JBoss is very simple. > The transaction id, as passed on the wire is of class > Object, and must thus be serializable at runtime. This > is called the transaction propagation context (TPC). > If the UT is obtained from a different VM than the > server: > The UT implementation used is org.jboss.tm.usertx.client. > When you obtain a UT by using JNDI, an RMI server > object is created on the server side. This RMI UT > session object does the actual work of controlling > transactions, BUT it only controls transactions in > the server VM where it resides. > When the UT is called to start a transaction, the > UT does a RMI call to the RMI server object, and the > RMI server object starts the transaction, obtains > the TPC for that transaction and returns it to the > UT. The UT then stores it for later use. > When a JRMP call is done from the client, the JRMP > proxy calls the UT (proprietary method > getTransactionPropagationContext()) to get the TPC > to pass on the wire. At server side this TPC is > translated into an actual Transaction. > At commit/rollback the UT calls the RMI server to > do the actual work, and then forgets about the > TPC it had stored. > If the UT is obtained from within the same VM as the > server: > The UT implementation used is > org.jboss.tm.usertx.client.ServerVMClientUserTransaction > This is very simple, and uses the transaction manager > to control transactions. > > So the fact the the UT implementation only controls > transactions in a single server may block what you > want. > > >>Now imagine that the webapplication wants to start a UserTransaction as >>you start the questionnaire, store each submission as you make it, and >>commit the whole thing IFF you finish.. > > > If the webapplication only calls beans in a single > server VM, this should be possible (though some changes > or extensions to the current UT implementation may be > needed). > > >>For this webapplication to successfully fail-over, the AppServer >>implementation must know how to move the UserTransaction between nodes. > > > If the UT is obtained from a different VM than the > server: > The getTransactionPropagationContext() method in the > UT implementation will return you a TPC that you can > serialize and move to another VM. > However, the UT will still consider the tx active, > even if the TPC is sent elsewhere and used to commit > from there. > But it shouldn't be hard to add a few extra methods > to UT: > Object grapTPC() would return the TPC and forget all > about the transaction. > void pushTPC(Object tpc) would work like starting a > transaction, but instead of actually starting a new > transaction, the TPC would denote the active > transaction. > If the UT is obtained from within the same VM as the > server: > The UT is a singleton that offloads all work to the > transaction manager. The TM implementation associates > transactions with threads, and implements the > interfaces TransactionPropagationContextImporter and > TransactionPropagationContextFactory. These interfaces > can be used as follows: > From the thread that started the transaction, get the > TPC using TransactionPropagationContextFactory. > From the thread where you now want to use the > transaction, set the TPC using interface > TransactionPropagationContextImporter. > After that, both threads are associated with the same > transaction and both threads may do whatever they > want with the transaction using their respective UTs. > > >>This goes above and beyond the spec - so if you can't do it - no >>problem. However, if it is possible,but not exposed, I would like to >>support it. > > > I think it is possible, though not currently exposed. > > >>Does that make it clearer ? > > > A lot, though I'm still in doubt if your UT is obtained > from within the same VM as the server. > > >>I will go into more depth, if things look hopeful. >> >>If it is too complicated/NYI - don't worry. I just thought that if there >>was a simple solution it would be nice to provide this functionality. > > > It is probably NYI, but it is probably not hard to > implement. > I wouldn't mind implementing support for this, if some > transaction code changes are needed. > > 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
