Hi Ann,
On 11/30/06, Ann Robinson <[EMAIL PROTECTED]> wrote:
Hi, Sanjiva, Thanks for the comments. I have tagged your comments with <sanjiva>text</sanjiva> to keep the indentation from getting too deep and put my responses below your comments with the tags <amr2>text</amr2>. Ann > <amr> > The save/restore of a MessageContext object hierarchy attempts to > reduce the duplication of parent-child objects in that MessageContext > object graph. The re-established MessageContext object graph keeps > the *Context objects to a single set and gets the Axis* objects > through the ConfigurationContext object associated with the AxisEngine > where the MessageContext was restored. So, the *Context objects are > unique across restored MessageContexts but the Axis* objects are > easily shared/re-used across restored MessageContexts. A future > refinement for the save/restore of the MessageContext is to find a way > to share *Context objects across restored MessageContexts. This is > actually a fairly small set of objects and involves the > OperationContext, ServiceContext, and ServiceGroupContext objects. > </amr> <sanjiva> Hmm. I don't think your approach will work if there's any serializable state the user has put into say ServiceContext and if that state gets modified by handlers after message reincarnation. There will be two different service contexts around and the "shared" value will no longer be shared. </sanjiva> <amr2> You have a good point. In particular, I think this would apply to properties that are set on the ServiceContext. I think that figuring out how to reconcile a restored ServiceContext with an existing ServiceContext would be worthwhile to add to the proposal. </amr2>
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. Chamikara
