axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <>
Subject Re: [AXIS2] Proposal for saving the message context
Date Fri, 01 Dec 2006 12:08:55 GMT
Hi Matt,

On 12/1/06, Matthew Lovett <> wrote:
> Hi all,
> Just a quick response to Chamikara's comments:
> "Chamikara Jayalath" <> wrote on 01/12/2006 00:45:00:
> >
> > I guess this applies not only to ServiceContexts but all the
> > contexts that get serialized. When two messages that share some top
> > level contexts get serialized, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.

I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.

What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.


> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message