struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <andrew.david.h...@gridnode.com>
Subject RE: [OT] Session & Context attributes in distributed env [WAS: RE: [OT]Servlet Context/Static Fields]
Date Thu, 21 Aug 2003 02:26:14 GMT
WTF!
Why are you spoofing my email Brian? (If that is your real name...)

We are not amused.

-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
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:craigmcc@apache.org] 
Sent: Wednesday, 20 August 2003 13:19 
To: Struts Users Mailing List; andrew.david.hill@gridnode.com 
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 , 
> andrew.david.hill@gridnode.com 
> 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:craigmcc@apache.org] 
> Sent: Monday, 18 August 2003 23:50 
> To: Struts Users Mailing List; andrew.david.hill@gridnode.com 
> 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 , 
> > andrew.david.hill@gridnode.com 
> > 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: struts-user-unsubscribe@jakarta.apache.org 
> For additional commands, e-mail: struts-user-help@jakarta.apache.org

> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message