David,
If it's that expensive, and given that it probably gets even more
difficult if one client can easily hit the same service multiple times
concurrently
It is expensive, but it maybe useful in certain uses cases. As you pointed
if there is a long running service invocation, then waiting till the end to
replicate will obviously increase the chances of conflicts when the same
service gets multiple hits.
So as I mentioned if we provide the ability to choose the replication
stratergy (Container managed or Service Managed) then the service author can
make an informed decesion about when to replicate and how often to
replicate.
It could be that if they want replication after every property change or
maybe after a bunch of property changes.
This gives a lot of flexibility.
// use case 1
ctx.setProperty("acct_no","A235523");
clusterManager.updateState();
// use case2
ctx.setProperty("acct_no","A235523");
//....... do more stuff
ctx.setProperty("ref_no","FSDSGSSG");
clusterManager.updateState();
Quite often we can't make all the decesions about functionality at design
time and certainly one size doesn't fit all. So if we can provide a sensible
default and the ability(responsibility) to override the default with what
makes more sense in a given situation we can mitigate some of the risks and
performance issues in more acceptable manner.
What do you think?
On 2/7/07, David Illsley <[EMAIL PROTECTED]> wrote:
If it's that expensive, and given that it probably gets even more
difficult if one client can easily hit the same service multiple times
concurrently, would it be a reasonable limitation for the first
version that the MessageReceivers which return before the business
logic is complete are not supported?
David
On 07/02/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> David,
>
> Exactly that was my concern.
> comments inline.
>
> On 2/7/07, David Illsley <[EMAIL PROTECTED] > wrote:
> > That's a difficult question to answer... flowComplete is called by the
> > AxisEngine after the MessageReceiver returns from invoke(). So in the
> > general case, yes, flowComplete will occur after the business logic is
> > complete.
> [RA] I currently (in the branch) have choosen do so in the engine just
below
> flowComplete() as the replication point for "state update".
> but as mentioned below it's not sufficient.
> > If, however, the MessageReceiver does work on a separate thread and
> > returns beffore the business logic is complete then flowComplete will
> > occur too early. However, I'd guess you'll struggle with this problem
> > with any approach.
> That is true. And the way to tackle is to track and replicate individual
> setProperty methods as and when they happen.
> But this is expensive and will have a performance impact :(
>
>
> > David
> >
> > On 07/02/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> > > David and Dims,
> > >
> > > Sorry I should have been more clear. What I meant by end of
invocation
> is to
> > > identify when the business logic has finished executing.
> > > Bcos during the course of web service operation, the web service
could
> be
> > > updating state.
> > >
> > > So does flowComplete() get executed after this ??
> > > I thought (I maybe wrong, please correct me) flowComplete() can get
> executed
> > > before "business logic" if finsihed executing.
> > >
> > > Regards,
> > >
> > > Rajith Attapattu
> > > Red Hat.
> > >
> > >
> > >
> > > On 2/7/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > > > Yep. David beat me to it :)
> > > >
> > > > On 2/7/07, David Illsley < [EMAIL PROTECTED]> wrote:
> > > > > Can't you use flowComplete() in the In_ONLY case?
> > > > > David
> > > > >
> > > > > On 07/02/07, Rajith Attapattu < [EMAIL PROTECTED]> wrote:
> > > > > > Deepal,
> > > > > >
> > > > > > I tried this approach and failed badly.
> > > > > > If it is only a IN_ONLY operation it is very difficult to
figure
> out
> > > when to
> > > > > > determine if an invocation is over or not.
> > > > > > For IN_OUT we can have handler in the inflow and outflow, but
> > > certainly
> > > > > > difficult in the above scenario.
> > > > > >
> > > > > > rajith
> > > > > >
> > > > > > On 2/7/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
> > > > > > > Hi Chamikara ;
> > > > > > > Do we really need to the listen to the event changes ?
> > > > > > >
> > > > > > > As I know whenever a message coming into the system there
will
> be
> > > many
> > > > > > > getProperty and setPoropert method calls. That simply impl
you
> that
> > > > > > > there are a number of context changes for a req. So you need
to
> > > update
> > > > > > > the replicas irrespective of the message, therefore you do
not
> need
> > > to
> > > > > > > listen to specific event . What you can do is , you can add
a
> > > handler
> > > > > > > (or handlers) to update the replicas when message coming to
the
> > > system
> > > > > > > and when a message going out from the system.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Deepal
> > > > > > >
> > > > > > > > Hi Deepal,
> > > > > > > >
> > > > > > > > The problem we had in clustering is having the listen to
> specific
> > > > > > > > events in the Axis2 execution. For example context
creation,
> > > context
> > > > > > > > removal, mep completion. So it is not possible to do it
with a
> > > module
> > > > > > > > based approach :-(.
> > > > > > > >
> > > > > > > > But performance is certainly in our mind.
> > > > > > > >
> > > > > > > > Chamikara
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > David Illsley - IBM Web Services Development
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> Developers
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
