axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: setMaintainSession
Date Wed, 16 Jan 2002 18:08:02 GMT
Init from Service, change locally (in Call) if needed - sounds good!

Russell Butek/Austin/IBM@IBMUS on 01/16/2002 12:13:50 PM

Please respond to

Subject:    Re: setMaintainSession

This change was made when we made stubs thread safe.  We did that by
instantiating a new Call object on every method call.  When we first did
that, we lost the session info.  In the stubs, session info is considered
to be at the stub level, not the method level; and since stubs are gotten
from the service, the service was the reasonable place to put the session
info.  This also makes sense when you consider that the session scope is
defined on deploy.wsdd.  This essentially maps to a service, not a method.

With all that said, however, I think you make a reasonable point.  We COULD
let the Call object get the session info from the service at construction
time, as we do now; but we could also provide a setMaintainSession on the
Call object if the user wanted to change it.

What do folks think?

Russell Butek

Doug Davis/Raleigh/IBM@IBMUS on 01/16/2002 10:09:20 AM

Please respond to

Subject:  setMaintainSession

I know this was discussed but I can't seem to find it in my
old notes - but why was setMaintainSession moved to
Service from Call?
To me, Call maps to a method and I can see cases where
one method would want to save state/session and another
would not - why would we not want this on a per Call basis?
I can always have my Call object reload itself with a new
method (from the wsdl) to call a new method and still maintain
the session stuff.  So, why was it moved?

View raw message