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. 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.. For this webapplication to successfully fail-over, the AppServer implementation must know how to move the UserTransaction between nodes. 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. Does that make it clearer ? 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. Jules Ole Husgaard wrote: > Jules Gosnell wrote: > >>I am rewriting my JBoss/Jetty distributable HttSession implementation. >> >>The spec (J2EE 1.3 & Servlet 2.3) suggests that I should be able to >>distribute Objects of types : >> >>Serializable >>EJBObject >>EJBHome >>Context - java:comp/env >>UserTransaction >> >>I would like to support UserTransactions. > > > I'm not sure what you want here. UserTransaction is a > local, non-serializable object. Distributing a UT does > not make sense to me, but it should be possible to > look it up in JNDI. > > >>e.g. a client can make a request to begin a transaction on one JBoss >>node, then make subsequent failed-over requests to other nodes that are >>executed within the same transaction context. > > > If the client is stand-alone (ie in a different VM than > the TM), it won't work. This is because the stand-alone > client UT support is limited to controlling transactions > on one server only (the server that gave you the UT via > JNDI). > I'm not sure about UT support for same-VM non-ejb clients, > would have to check the code. > > >>I'm no transaction guru..... :-( >> >>The UserTransaction API does not give me access to any unique, >>distributed ID (like EJBObject and EJBHome handles etc.) - so if this is >>going to happen, it will be via the proprietary interface of the >>UserTransaction's implementation. > > > The ID exists, but the JTA standard seems very secretive > about it. It is only exposed to xa resources. > > But I cannot see why you need it here. > > Are you trying to move an active transaction started > by a UT to another server in another VM? > That might be possible, if you use the Tyrex TM, and > some JBoss-specific API for importing and exporting > transaction propagation contexts (TPCs, basically > serializable transaction ids). > > >>Questions: >> >>Is it possible to distribute UserTransactions if all webcontainers are >>not sharing the same EJB container (but all EJB containers are sharing >>the same DB)? > > > See above. I'm not sure what you mean when you say > "distribute UserTransactions". > > >>Or if all webcontainers are sharing the same EJBContainer ? >> >>Or should I forget supporting this ? >> >>If possible - how could it best be achieved ? > > > I probably know - only I'm not sure what you try > to achieve. > > 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
