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
