On Wed, 20 Aug 2003, Andrew Hill wrote: > Date: Wed, 20 Aug 2003 13:38:29 +0800 > From: Andrew Hill <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts <[EMAIL PROTECTED]> > Subject: RE: [OT] Session & Context attributes in distributed env [WAS: > RE: [OT]Servlet Context/Static Fields] > > Im developing on Tomcat, but the application is a product that the customers > deploy on their own appserver - so needs to be container independent (in > theory ;-> Usually we set up an appserver for them). At this stage we arent > doing distributed deployments for the presentation tier so it hasnt been an > issue, but of course its one of those things I know is going to happen > sooner or later so Id like to be ready for it. I think load balancing would > be the main concern. Failover would be important for the business tier ejbs > n'stuff, but for the UI not really vital (though I wouldnt be surprised if > its considered important for marketing purposes!). > > At the moment I think Im breaking a fair few of the distributability rules > (such as putting non-serializables into session scope). > > <snip> > It can only be migrated "in between" requests. When it is migrated, all of > the session attributes (which must be Serializable) are taken along with it. > </snip> > > What you say about the session only being replicated between requests does > take quite a weight of my mind though! Getting rid of the naughty > non-serializables shouldnt be too difficult I hope. > > When you say "all of the session attributes" , does that mean literally all > of them or just ones that have had setAttribute() called on them since the > previous replication? (or is this too container dependant) A fair few of > these objects in my app are getting modified internally by layers that know > nothing of the servlet api. >
The design intent is that a web application should not be able to tell that it got moved -- it still keeps doing setAttribute() and getAttribute() calls against the session, and they still work, and any attribute key that has been set will still be there. The quality of service characteristics of how moving happens (i.e. when and how often the actual data is copied), though, are definitely container specific -- check the rules on the server(s) you plan to deploy to. Craig > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 20 August 2003 13:19 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: [OT] Session & Context attributes in distributed env [WAS: > RE: [OT]Servlet Context/Static Fields] > > > On Wed, 20 Aug 2003, Andrew Hill wrote: > > > Date: Wed, 20 Aug 2003 11:17:54 +0800 > > From: Andrew Hill <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: Struts <[EMAIL PROTECTED]> > > Subject: [OT] Session & Context attributes in distributed env [WAS: RE: > > [OT]Servlet Context/Static Fields] > > > > Thanks Craig, > > > > I can see that there is a lot I still have to learn about this area. > > > > Where (other than the spec itself which should of course be my first stop) > > would be a good place to get info on these things? > > > > I would immediately go to the developer docs for the particular app server > that you're using, to see what they suggest for ensuring that session > attributes are replicated at appropriate times. Next, I'd go peruse the > configuration options for that app server, to see what kind of tweaks I'm > able to play with for maximizing performance (well, usually it's an issue > of minimizing the costs of supporting failover :-). > > Since this whole area of functionality is platform specific, the only > place you'll find the answers is in platform-specific documentation. > > > Its quite alarming to think that if you set a session attribute it might > not > > be available when you process the next request, and if one sets a whole > lot > > of stuff if the context (including the struts config objects) that they > > might only be available on the machine that created them! hehe Im > obviously > > not grokking this at all. > > > > There actually is one important rule in the servlet spec that reduces the > amount of uncertainty -- it is not legal for an app server to migrate a > particular session from one system to another while there is a request > being processed against that session. It can only be migrated "in > between" requests. When it is migrated, all of the session attributes > (which must be Serializable) are taken along with it. If you're just > using multiple servers for load balancing, and don't care much about > failover, you really shouldn't have to worry about this particular issue. > > But, if you care about failover, the whole name of the game is finding the > right balance between overhead and failover reliability, for your > particular application. It's hard to provide general advice on that sort > of issue. > > Craig > > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > > Sent: Monday, 18 August 2003 23:50 > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: RE: [OT]Servlet Context/Static Fields > > > > > > On Mon, 18 Aug 2003, Andrew Hill wrote: > > > > > Date: Mon, 18 Aug 2003 17:12:34 +0800 > > > From: Andrew Hill <[EMAIL PROTECTED]> > > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > > > [EMAIL PROTECTED] > > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > > Subject: RE: [OT]Servlet Context/Static Fields > > > > > > If your in a distributed environment changes you make to properties of > > those > > > static classes will not be propogated to other JVMS (or indeed other > > > classloaders), whereas the stuff in ServletContext should be (though Id > > love > > > to hear an explanation of how it knows when to do it!). > > > > > > > Propogation in a distributed app server is actually only guaranteed (in > > the J2EE specs) for *HttpSession* attributes, not *ServletContext* > > attributes. It's certainly possible for a server to offer replication of > > context attributes as well, but you can't rely on that to be portable. > > > > The strategy for knowing when to replicate session attributes (and it > > would probably apply to context attributes as well) is typically a > > configuration option in a server-specfic deployment descriptor. One could > > imagine doing it on a timed basis, or whenever setAttribute() is called > > again, or having some out-of-band method of signalling the server that > > this attribute has been modified. > > > > Craig > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
