Glen, Thanks again for the info. I have one more question regarding the Axis-provided session maintenance that I was hoping someone could answer:
In JSP/Servlets, a javax.servlet.http.HttpSession object "[calls] the valueUnbound() method of all objects in the session implementing the HttpSessionBindingListener interface." Does an org.apache.axis.session.Session do something similar? I'd like to use this built-in functionality, but mostly for storing jdbc Connection objects, and I would really like an opportunity to call the close() methods on these when a session times out. Andrew At 05:09 PM 5/9/2002 -0400, you wrote: >Hi Andrew! > >When you set "scope=session" on a service, the JavaProvider will actually >use the Session object that is associated with the MessageContext to store >the service object (under the service's name - so you should actually be >careful not to overwrite it if you use the Session in your own code!) and >get it back on each subsequent request. Note that Session is an >interface, and there are currently two implementations - the >SimpleSession, and the AxisHttpSession, which wraps a servlet >HttpSession. The AxisServlet plunks an AxisHttpSession into the >MessageContext if appropriate, and the SimpleSessionHandler plunks in a >SimpleSession. The idea there is that the Handlers/Providers shouldn't >care HOW you implement sessions, just that they're there. > >So you may either use cookies OR the SOAP-based session handlers, and in >either case you end up with a Session object in your MessageContext. If >your service is session scoped, you will also ensure that you get the same >service object for every request associated with a given session. Hence >you can certainly use state in your service object, but the explicit usage >of the Session object is also useful, especially in Handlers which do want >to maintain state themselves, but don't want to be tied to a particular >service object class. > >--Glen > > > -----Original Message----- > > From: Andrew Vardeman [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 09, 2002 11:15 AM > > To: [EMAIL PROTECTED] > > Subject: RE: stateful service example (no cookies) > > > > > > hehe--nope, didn't know that :) Guess it pays to read one's > > Javadocs, but > > then I get lost fast in Javadocs. At least I know I was on > > the right track > > since I was about to implement everything that's already there-- > > > > So I get that this handler reads the session ID and places > > the appropriate > > SimpleSession object in the MessageContext. It makes sense > > that I can > > store session info in the SimpleSession and it'll be there on > > the next > > request. Something from Stan's cookie-based Stateful Service > > example is > > confusing me: he doesn't bother with SimpleSession at all; he > > saves a value > > in a member field of his service class, and it's there on the next > > request. I understand that this is because the service has > > session scope, > > but what is really going on? There is an instance of the > > service for each > > distinct session, right? At what point in processing the > > incoming request > > does Axis determine which instance of the service to hook the > > request up > > with? In the transport chain? It seems like selecting the > > right instance > > of the service is a job for something outside of any one > > handler's control... > > > > I guess what I'm wondering is whether the parameter "scope" > > is applicable > > to a service using SimpleSessionHandler. If I say <parameter name = > > "scope" value = "session" />, does that imply cookie-based session > > maintenance? What scope should I set for a service that uses > > SimpleSessionHandler? If session scope, do I get the same > > benefit as in > > Stan's example, where member fields of my service class stick > > around? If > > so, why the SimpleSession object? > > > > Thanks, > > > > Andrew > > > > At 11:18 PM 5/8/2002 -0400, you wrote: > > > > >Hi Andrew! > > > > > >Just an FYI - you do realize that we already have SOAP header-based > > >sessions built in to Axis, right? I haven't looked at your > > code, so I'm > > >not sure if the functionality we provide is what you're > > looking for, but > > >it's there. Essentially, if you drop a Handler > > (SimpleSessionHandler) > > >into your request & response flows, we will automatically > > handle session > > >management and timeout issues for you, allowing you to use > > exactly the > > >same mechanism to store + retrieve session data as you would for > > >cookie-based sessions. > > > > > >--Glen > > > > > >
