Re: [Axis2] How to figure out the end of a request ?

[Rajith Attapattu <ra...@gmail.com>]

Hi All,

While hashing out the requirments for session mgt and a WADI clustering
implementation the following concerns were raised,

>From a clustering perspective it is important to retrive the session
immediately before invoking the business logic and notifying the session mgr
immediately after. The  current implementation has 2 handlers at the
begining of the inflow and at the end of the outflow. The session handler in
the inflow retrives the session_id from the soap message and also retrives
the session object as well. This is not very good in a clustering scenario
as retriving the session object could be expensive and if there is an error
condition in the handler chain then all the work done upfront is wasted.

Hence we are need to identify the points, where we can plug in the session
retrival and passivation code immediately before and after invoking the
business logic.

Since we deal with the following Message Exchange Patterns, we need to find
a clear end point where we can denote that a request is finished.
I would appreciate if the experts can point us in the right direction. I
want to implement this with the least possible impact on the core, so
suggestions are greatly appreciated.

1. IN-OUT (Both sync and async)
2. IN-ONLY

The best way to trap both the above MEPS is to proxy the receive() in the
MessageReceivers.

Problem
----------------------------
In the Synch case it's straight forward as we can wrap around the
recive(MessageConetxt ctx) method in the MessageReceivers. It's executed in
the same request thread, so we can proxy the receive method and retrive the
session just before calling the actual receive method and then passivate the
session soon after.

However in the Async case the processing happens in a different thread than
then request thread. So we will need a different stratergy of hooking up
with the CB class (possibly the handleResult() method) to idenfity the end
of the request.

Is this the only way?
Do u guys have a better way of handling both asyc and sycn in a generic way
rather than the above two approaches?

This is where I need to your help in figuring it if I am thinking on the
right line?

Any other suggestions other than using the receive() in the MessageReceiver
interface?

Regards,

Rajith