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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
