axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Longshaw" <a...@blueskyline.com>
Subject Re: Maintain session state between Calls
Date Wed, 28 Nov 2001 15:26:10 GMT
Sorry to intrude guys, but this discussion seems
ripe for asking the question "give me a scenario or
two where someone would want this behaviour".

On the specific question, what sort of state would
the caller want to maintain on the server that they would
access over two different types of transport?

On the wider question of context, the main things
that spring to mind are security and transaction context
that would need to be propagated between various
Web Services as part of a user request. I would think
that this belongs in part of the SOAP header that
is set as part of a higher-level session context i.e. not
in at the transport or call-context level.

Please let me know if I'm missing anything or if
I'm being too simplistic about this.

Cheers

Andy

----- Original Message ----- 
From: "Glen Daniels" <gdaniels@macromedia.com>
To: <axis-user@xml.apache.org>
Sent: Wednesday, November 28, 2001 12:56 PM
Subject: Re: Maintain session state between Calls


> 
> Huge -1.  It seems much simpler to me to cleanly scope objects as we're
> doing now, and design a correct solution to any new requirements which
> arise.  If data needs to be shared across contexts, there should be
> someplace to store it which is also shared across contexts (i.e. Call).
> 
> A possible solution for the Transports problem (off the top of my head) is
> that they could store data in the Call instead of keeping it inside
> themselves.  More on this later.
> 
> Gotta go - see you live in a half hour, Doug. :)
> 
> --Glen
> 
> ----- Original Message -----
> From: "Doug Davis" <dug@us.ibm.com>
> To: <axis-user@xml.apache.org>
> Sent: Wednesday, November 28, 2001 7:49 AM
> Subject: Re: Maintain session state between Calls
> 
> 
> > Each handler should be responsible for cleaning
> > up after itself - so anything left in the messageContext
> > should be considered nontransient.  Yes this would
> > be a change in the current design but one that I think
> > would cause less confusion since it would mean less
> > objects to maintain and support.  Plus, going back to
> > the problem at hand - 2 http transport objects can not
> > _easily_ share data right now.
> > -Dug
> >
> >
> > "Glen Daniels" <gdaniels@macromedia.com> on 11/28/2001 07:43:47 AM
> >
> > Please respond to axis-user@xml.apache.org
> >
> > To:   <axis-user@xml.apache.org>
> > cc:
> > Subject:  Re: Maintain session state between Calls
> >
> >
> >
> > > No its not quite like switching IP addresses (could be though :-).
> > > There can be cases where someone switches from one transport
> > > object to another but BOTH of them use, for example, HTTP.
> > > In that case the HTTP specific session stuff should shared - which
> > > right now they will not be.  The messageContext is right place
> > > to stick this stuff since it will be shared across invoke()'s
> > > on the same Call object.
> >          ^^^^^^^^^^^^^^^^
> >
> > One more time, with feeling - the MessageContext is for PER-REQUEST data,
> > and should indeed be cleared out if it's going to be reused at all.  As
> you
> > note, the Call object stays the same, and in fact there is a perfectly
> > happy
> > mechanism in the Call object to store properties which you want to be set
> > on
> > every request.
> >
> > > Right now in messageContext.reset() I believe we erase everything
> > > in the "bag" - I would prefer if we didn't and we instead allowed
> > > handlers (ie. transport objects) to store data in there that they
> > > can then regrab later if they want - regardless of who put it there.
> >
> > That would cause a lot of potential problems trying to figure out which
> > MessageContext properties were "transient" and really the result of a
> > particular processing chain, and which ones were "persistent" and should
> > stick around.  Keeping the persisitent stuff a layer above solves this
> > problem neatly, and avoids a lot of confusion for people trying to write
> > Handler chains.
> >
> > --Glen
> >
> >
> >
> >
> 


Mime
View raw message