WTF! Why are you spoofing my email Brian? (If that is your real name...) We are not amused.
-----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, 20 August 2003 13:38 To: Struts Subject: RE: [OT] Session & Context attributes in distributed env [WAS: RE: [OT]Servlet Context/Static Fields] Hello there, A quick question on your comment Craig <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> When using the session to store objects, should they 'always' be serializeable or is that only a requirement, when you are using session sharing between multiple servers? Thanks Brian >>> "Andrew Hill" 08/19/03 11:38pm >>> 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). 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. 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. -----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 > Reply-To: Struts Users Mailing List , > [EMAIL PROTECTED] > To: Struts > 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 > > Reply-To: Struts Users Mailing List , > > [EMAIL PROTECTED] > > To: Struts Users Mailing List > > 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]
