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 Sun, 24 Sep 2006 02:01:31 GMT
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
>
>


-- 
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