axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Date Tue, 10 Oct 2006 13:40:16 GMT
Sanjiva,

We had terrible problems with TLS in Axis1...let me recollect my
thougts and post.

-- dims

On 10/10/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> I think I agree with you. How about we drop setOperationContext() and
> introduce Axis1-style MessageContext.getCurrentContext() which returns
> it for this thread? Have to be careful to put it in TLS and take it off!
>
> We must be careful to tell users that instance variables are not
> supported; you have to use MessageContext properties to store state (or
> wherever else).
>
> Sanjiva.
>
> On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote:
> > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .
> > I set the priority to blocker as David suggested.
> >
> > IMHO it's probably best to drop the method. Many users will use it in an
> > intuitive but wrong way. The only way to store the data it provides is an
> > instance variable, and telling users to either use only request scope or use
> > a ThreadLocal to store the data does not seem to be compatible with the
> > rule of least surprise. Something like MessageContext.getCurrentContext()
> > in Axis 1 might be better.
> >
> > Bye,
> > Christopher.
> >
> > Davanum Srinivas wrote:
> > > Chris,
> > >
> > > Can you please raise a new issue in JIRA?
> > >
> > > thanks,
> > > dims
> > >
> > > On 9/23/06, Christopher Sahnwaldt <chrisahn@gmx.net> wrote:
> > >> Something worries me:
> > >>
> > >> > setOperationContext(OperationContext) - per call.  The messageContext
> > >> > can be obtained to gain per call instance information.
> > >>
> > >> That doesn't seem to be thread-safe, does it? If I understand this
> > >> correctly, one service object is created per application (if the
> > >> service has application scope). When a request comes in, Axis calls
> > >> the setOperationContext method, and the service object may store the
> > >> OperationContext or the MessageContext. Then Axis calls the actual
> > >> service method, in which the service code can access the stored
> > >> OperationContext or MessageContext. But what if two requests come
> > >> in almost simultaneously? The following sequence of method calls
> > >> may occur:
> > >>
> > >> - Axis calls setOperationContext with context for request A, the
> > >>   service object stores the context in an instance field.
> > >> - Axis calls setOperationContext with context for request B, the same
> > >>   service object stores the context in the same instance field and
> > >>   thus *overwrites* the context for call A.
> > >> - Axis calls the service method with the input parameters for request A.
> > >> - The service method processes the call, using data from the stored
> > >>   context, and thus *mixes the input parameters for call A with the
> > >>   context data for call B*. Anything can happen...
> > >> - Finally, Axis calls the service method with the input parameters
> > >>   for call B, the service method processes the call, using data from
> > >>   the stored context, and thus correctly uses the input parameters
> > >>   for call B with the context data for call B. Probably ok, unless
> > >>   the service method updated the context in some way during the call
> > >>   for request A.
> > >>
> > >> But I hope I'm wrong or misunderstood or forgot something... ;-)
> > >>
> > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(),
> > >> which gives access to the MessageContext *for the current thread*
> > >> from within any service method, without the need for a
> > >> setMessageContext (or setOperationContext) method on the service
> > >> object.
> > >>
> > >> Bye,
> > >> Christopher.
> > >>
> > >>
> > >> Tony Dean wrote:
> > >>
> > >> > Can we fully document the logical semantics behind each method?
> > >> >
> > >> > init(ServiceContext) - To me this use to mean application init.
> > >> Now it means session init.  However, when running
> > >> scope="Application", it is analogous to application init since you
> > >> will only have one session;  but, still probably not appropriate to
> > >> think in those terms.
> > >> >
> > >> > How should an application use this method?  A session use-case
> > >> would be nice.
> > >> >
> > >> > destroy(ServiceContext) - inverse of init()
> > >> > Use-case?
> > >> >
> > >> > setOperationContext(OperationContext) - per call.  The
> > >> messageContext can be obtained to gain per call instance information.
> > >> >
> > >> > StartUp() - one time initialization... DB connections etc...
> > >> > Shutdown() - inverse of StartUp()
> > >> >
> > >> > Any more insight or corrections to pattern usage would be grateful...
> > >> >
> > >> > Thanks.
> > >> >
> > >> > -----Original Message-----
> > >> > From: robert lazarski [mailto:robertlazarski@gmail.com]
> > >> > Sent: Friday, September 15, 2006 8:49 AM
> > >> > To: axis-dev@ws.apache.org
> > >> > Subject: Re: Improvements to Service life cycle in handling
> > >> >
> > >> > That makes sense to me. I've been using startUp() and it doesn't
> > >> really fit with the other methods of the interface in its current
> > >> form. +1 for 1.1 since its interface changes and it'd be better to do
> > >> it now.
> > >> >
> > >> > One question: Currently you need this in services.xml to get
> > >> startUp() to invoke:
> > >> >
> > >> > <parameter name="load-on-startup" locked="false">true</parameter>
> > >> >
> > >> > I plan on testing this when its ready ... since the spring tutorial
> > >> depends on it ... so I thought I'd ask if the services.xml param will
> > >> remain the same.
> > >> >
> > >> > Thanks,
> > >> > Robert
> > >> >
> > >> > On 9/14/06, Deepal Jayasinghe <deepal@opensource.lk> wrote:
> > >> >
> > >> >> Hi All;
> > >> >>
> > >> >> Currently we have an interface called Service and which has few
> > >> >> methods that are used to manage session (or else user can add
those
> > >> >> method into service impl class w.o implementing the interface).
And
> > >> >> that interface has the following methods ;
> > >> >>
> > >> >> - startUp
> > >> >> - init
> > >> >> - setOperationContext
> > >> >> - destroy
> > >> >>
> > >> >> Three of them are for managing service life cycle ;
> > >> >> - init - will be called when the session start
> > >> >> - setOperationContext - immediately before calling actual java
method
> > >> >> - destroy - will be call when the session finishes
> > >> >>
> > >> >> Remember all those method work if and only if you use Axis2 default
> > >> >> message receiver or you code gen.
> > >> >>
> > >> >> The method startUp is not session related method , which is useful
> > >> >> when you want to initialize database connections , create thread
etc
> > >> >> ... at the time when you deploy the service. In the mean time
> > >> >> interface name Service is bit confusing to me AFAIK it should
be
> > >> >> ServiceLifeCycle. And having method like startUp in that interface
> > >> confuses the users.
> > >> >>
> > >> >> So how about the following changes ;
> > >> >> - Rename Service interface into ServiceLifeCycle
> > >> >> - Then remove startUp method from that interface.
> > >> >>
> > >> >> There should be a some other interface (like Module interface)
and
> > >> >> which should be optional as well , to have the method startUp.
If
> > >> >> someone want to open DB connection or anything at the time of
service
> > >> >> deploying , then he need to implement that interface (and for
me
> > >> which
> > >> >> is identical to Module interface). So with this change service
> > >> element
> > >> >> inside the services.xml will be change to following
> > >> >>
> > >> >> <service name="foo" *class="implementation class of the interface
"*>
> > >> >> <parameter name="ServiceClass">ServiceClass</parameter>
> > >> >> </service>
> > >> >>
> > >> >> Here the class attribute is optional , so if someone want to have
> > >> >> loadonStartup feature then he need to implement the Service interface
> > >> >> (new one) and put the impl name as the class attribute. This is
very
> > >> >> useful if your service implementation class is not java (if you
are
> > >> >> writing a groovy serice).
> > >> >>
> > >> >> So new Service interface will be look like follows; public interface
> > >> >> Service{ //will be called when service is deployed public void
> > >> >> startUp(ConfigurationContext configctx, AxisService service);
//will
> > >> >> be called when Axis2 server showdown or when service removed from
the
> > >> >> system public void shutDown(ConfigurationContext configctx,
> > >> >> AxisService service); }
> > >> >>
> > >> >> And ServiceLifeCycle interface will look like below;
> > >> >>
> > >> >> public interface ServiceLifeCycle {
> > >> >> public void init(ServiceContext sc);
> > >> >> public void setOperationContext(OperationContext operationContext);
> > >> >> void destroy(ServiceContext sc); }
> > >> >>
> > >> >>
> > >> >> I am +1 on doing this for Axis2 1.1 :)
> > >> >>
> > >> >> Suggestions ........
> > >> >>
> > >> >> Thanks
> > >> >> Deepal
> > >> >>
> > >> >>
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >> >
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message