axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thilina Gunarathne" <cset...@gmail.com>
Subject Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Date Tue, 10 Oct 2006 18:01:35 GMT
Hi Deepal,
>Deploying a service in application scope , user want to have once
>service impl instance (im I were a user , I want that )

Frankly I don't... Service impl class is a Axis2 bundled MR(eg:
RawXMLInOut..) specific notion... Service impl is meaning less if the
user has written a custom MR.. One example would be a BPELEngine
(which I did :) ), where we had our own Message Receiver and we stored
all the  state data in the service context.. See
http://issues.apache.org/jira/browse/AXIS2-1133 this too..

>so we're now talking about
> setting a TLS OperationContext.getCurrentContext() into the AxisEngine,
> right before it calls the MessageReceiver

I'm not sure about the impact of this change... If this is not a
straight forward change I doubt whether we should do this at this
moment... Don't want to take any chances towards 1.1 :(...

> We should maintain both ,I mean
> - should have only one  serviceContext
> - and only one service impl

any concrete use cases.... Use cases which cannot be implemented using
by storing the state data in the service context...


> What if user want to keep local variable inside the impl class . I know
> that is not the best practice bt ppl are using that .
Then why we gonna encourage that ??

Thanks,
~Thilina

>
> > IMO anybody can use
> > the ServiceContext to store whatever the state data needed to be
> > shared across the life of the service...Are there any special cases
> > where we can't do that.. If there aren't any reasons my suggestion is
> > to  create the service object per invocation.
> >
> > Also a user who uses the application scope might most probably be
> > working in the messagereceiver(MR) level, since MR is known to be the
> > ultimate message recipient in Axis2. One possible example is a BPEL
> > engine.. In that case the concept of one service object for the life
> > time of the service invalidates.. AFAIKS AXIS2-1133 is another
> > implication of this design...
> >
> > Thanks,
> > Thilina
> >
> > On 10/10/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> >
> >> Other choices?
> >>
> >> The approach we used back in ApacheSOAP was to tell the user to add an
> >> additional first parameter to their methods if they wanted the
> >> context .. so the signature would have an additional param and that'd
> >> tell us to do the right thing. Very thread safe.
> >>
> >> Need to avoid reflection - but can be done by a codegen flag. For RPC
> >> case its reflective anyway so its not a big deal.
> >>
> >> Sanjiva.
> >>
> >> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote:
> >> > 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
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/

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