Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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=falsetrue/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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Ok... Here's my suggestion.. Let's create new service objects per invocation.. AFAIK two things happen when we deploy a service in application scope. One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one service class object throughout the life of the service, serving for all the requests.. Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to shared throughout the life of the service. IIRC this is one of the use cases we came up with for the Axis2 context hierarchy- to make the engine stateless.. On the other hand, i don't see any reason for maintaining a single service object throughout the life of the service. IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Thilina Thilina Gunarathne wrote: Ok... Here's my suggestion.. Let's create new service objects per invocation.. I do not agree with this approach :) , with this if some one deploy a service with application scope then there will be multiple instance of same service impl class. Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) btw : there was a JIRA issues on this couple of month ago. Here in ApacheCon US , we are discussed abt the this issue deeper ,and we agreed to use Sanjiva's suggestion. MessageContext.getCurrentContext(). P.S : Deepal41: hi dims [12:06]GlenD: [11:59] GlenD so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] GlenD and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] GlenD so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move saveTCCL(messageCtx); [12:07]Deepal41: into AxisEnine too [12:07]Deepal41: what do u think dims ? [12:07]dims: ok [12:08]dims: sounds good [12:08]dims: need to get Ali to test his ejb stuff and get Robert to test spring support again after that change [12:09]GlenD: +1 [12:09]sanka has joined [12:10]Deepal41: +1 [12:12]Deepal41: one more q [12:13]Deepal41: is that OperationContext.getCurrentConetct(); [12:13]GlenD: getCurrentContext() [12:13]Deepal41: or MessageContext..getCurrentContext(); [12:14]GlenD: Personally, I prefer MC.getCurrentContext() [12:14]GlenD: but I'm fine with OC.getCurrentContext() too [12:14]Deepal41: how abt others [12:14]dims: Let's write it up and post to the list (with both options) [12:14]GlenD: I just think you don't lose anything by doing it in the MC, and it allows you to get the current MC properties without having to know which one to ask for from the OC [12:14]GlenD: sure, dims [12:15]Deepal41: ok , then let's go with MC.getCurrentContext(); [12:15]dims: was just reading email from incubator folks about not taking decisions on the irc :) [12:15]Deepal41: :) [12:16]Deepal41: hmm , I am +1 on MC.getCurrentContext(); [12:17]GlenD: hee hee [12:17]GlenD: we were just talking about IRC vs email a bit ago [12:17]dims: guys read the email from thilina as well [12:17]GlenD: k AFAIK two things happen when we deploy a service in application scope. One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one service class object throughout the life of the service, serving for all the requests.. We should maintain both ,I mean - should have only one serviceContext - and only one service impl Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to shared throughout the life of the service. IIRC this is one of the use cases we came up with for the Axis2 context hierarchy- to make the engine stateless.. Totallly agrred. On the other hand, i don't see any reason for maintaining a single service object throughout the life of the service. What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,Here is my concern. If you have application scope the expectation is that we have a single instance throught the life of the app.So I could be initializing very expensive stuff in my init() and thats ok bcos the expectation is that you do that only once. Imagine if we have to do this for every invocation bocs we choose to create a new object for every invocation?This could be a severe performance hit as I maybe doing very expensive object creations.So in my opinion we have to look at a different stratergy from a performance POV. Regards,RajithOn 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Ok... Here's my suggestion.. Let's create new service objects per invocation..AFAIK two things happen when we deploy a service in application scope.One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one serviceclass object throughout the life of the service, serving for all therequests..Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to sharedthroughout the life of the service. IIRC this is one of the use caseswe came up with for the Axis2 context hierarchy- to make the engine stateless..On the other hand, i don't see any reason for maintaining a singleservice object throughout the life of the service. IMO anybody can usethe ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special caseswhere we can't do that.. If there aren't any reasons my suggestion istocreate the service object per invocation.Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be theultimate message recipient in Axis2. One possible example is a BPELengine.. In that case the concept of one service object for the lifetime of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design...Thanks,ThilinaOn 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in anintuitive but wrong way. The only way to store the data it provides is aninstance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with therule of least surprise. Something like MessageContext.getCurrentContext()in Axis 1 might be better. Bye,Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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. -
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Deepal, Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) Frankly I don't... :) Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if the user has written a custom MR.. yes , I agree. btw we use all those concept in code gen as well , I mean all the generated MR support all those. One example would be a BPELEngine (which I did :) ), where we had our own Message Receiver and we stored all the state data in the service context.. yes , as I told you earlier thats the perfect way , but there are users how want to store values in service impl. (And for me I think that is not that bad when you deploy a service in application scope) See http://issues.apache.org/jira/browse/AXIS2-1133 this too.. so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver I'm not sure about the impact of this change... If this is not a straight forward change I doubt whether we should do this at this moment... Don't want to take any chances towards 1.1 :(... no , if we are going to make this change we have to do that before 1.1 , and I dont think the change we are planing to do will affect that much :) We should maintain both ,I mean - should have only one serviceContext - and only one service impl any concrete use cases Use cases which cannot be implemented using by storing the state data in the service context... What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . Then why we gonna encourage that ?? Thanks, ~Thilina IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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
RE: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,I understand your use case about having to create a new object for each invocation.But your use case is clearly in the minority. (meaning people will not do that often)So if you have a special requirment like that then why not use the concept of ServiceObjectSupplier. So if u specify a custom service object supplier which creates a new service object irrespective of the scope then you are fine.We should not in my opinion change the general expectation of the users at large to implement special cases. As a user my understanding of Application Scope is that I have a Service that will live for the life of the application.And I may have (or choose to do so) instance variables that I maybe relying across multiple invocations. I may also want to init expensive resources in my init().All these assumptions which are based on the general idea about application scope are no longer valid if choose to create new objects each time. Regards,RajithOn 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi Deepal,Deploying a service in application scope , user want to have onceservice impl instance (im I were a user , I want that )Frankly I don't... Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if theuser has written a custom MR.. One example would be a BPELEngine(which I did :) ), where we had our own Message Receiver and we storedall thestate data in the service context.. See http://issues.apache.org/jira/browse/AXIS2-1133 this too..so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiverI'm not sure about the impact of this change... If this is not astraight forward change I doubt whether we should do this at thismoment... Don't want to take any chances towards 1.1 :(... We should maintain both ,I mean - should have only oneserviceContext - and only one service implany concrete use cases Use cases which cannot be implemented usingby storing the state data in the service context... What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that .Then why we gonna encourage that ??Thanks,~Thilina IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is tocreate the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:I think I agree with you. How about we drop setOperationContext() andintroduce Axis1-style MessageContext.getCurrentContext() which returnsit for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are notsupported; you have to use MessageContext properties to store state (orwherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call.The messageContext can be
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. Was this a misunderstanding or is this a change? David On 10/10/06, Tom Jordahl [EMAIL PROTECTED] wrote: While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. I agree it doesn't need to be earlier. From Deepal earlier in this thread: Deepal41: hi dims [12:06]GlenD: [11:59] GlenD so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] GlenD and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] GlenD so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move ... David -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Hi Sanjiva Weerawarana wrote: On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. Yes that was the final conclusion. FYI: Deepal: hi dims [15:07]Deepal: u there [15:08]Deepal: I dont think we can move saveTCCL(messageCtx); in AxisEngine [15:23]GlenD: dims? [15:23]GlenD: u there? [15:26]dims: ping [15:26]GlenD: hey [15:26]GlenD: so Deepal and I were chatting about the context stuff [15:26]dims: yes [15:26]GlenD: and ended up coming up with a very interesting idea which we wanted to run past you [15:26]dims: sure [15:26]GlenD: I think it's too big a change for now, but it's pretty cool for a future release [15:27]dims: we need to make a list of those :) [15:28]GlenD: the issue is that there's a lot of code duplication amongst MessageReceivers [15:28]dims: ah. that one :) [15:28]GlenD: if we want this setTCCL stuff and the setCurrentContext stuff to live in the MRs, it's hard to figure out where to put it so it isn't dup'ed everywhere [15:29]dims: call back to engine? [15:29]dims: sorry...go ahead. [15:29]GlenD: so we're wondering if you could maybe factor it out into a single AbstractMessageReceiver [15:29]GlenD: which would do the TCCL/Context stuff, then call invokeBusinessLogic() but pass only the OperationContext [15:29]dims: we have one of those [15:30]dims: AbstractMessageReceiver [15:30]GlenD: not have separate ones that pass either (inContext) or (inContext, outContext) [15:30]GlenD: we do? [15:30]dims: we need to structure it better [15:30]Deepal: we have 4 of them :) [15:30]GlenD: right [15:30]GlenD: we have 4 [15:30]dims: org.apache.axis2.receivers.AbstractMessageReceiver [15:31]dims: ah. i see [15:31]Deepal: and we are thinking of chaning invokeBusinessLogic signature [15:31]GlenD: only the lower level ones (AbstractInOnlyMR, etc) actually have receive() [15:31]GlenD: the top level one doesn't do anything [15:31]GlenD: except hold utility methods [15:31]dims: any cleanup is very welcome! sorely needed in this area. [15:31]dims: +1 [15:31]GlenD: so the interesting part is that SOMEONE needs to know to take the outMessageContext from the operationContext and send it [15:31]dims: please make sure you handle the spring scenario [15:31]Deepal: invokeBusinessLogice will take OperationContext as it argument [15:32]GlenD: that's the real difference between in and inout [15:32]dims: and then check isinstanceof? [15:32]GlenD: we're wondering if there's a way to genericize that by calling invokeBusinessLogic() and then something like complete() or doNext() [15:32]GlenD: but we need to think about it a little more I think :) [15:33]dims: yep... [15:33]dims: pre and post? [15:34]GlenD: (thinking here) [15:34]dims: first step is to collapse all 4 into 1 AbstractMessageReceiver? [15:34]dims: somehow [15:34]GlenD: that was the thought yes but we're seeing if it can work [15:35]dims: then adjust the calls to invokeBusinessLogic and maybe call something before it and something after it for special processing for different MEP's? [15:36]dims: are we looking for clean code or new feature here? [15:36]Deepal: I think both :) [15:37]dims: and the new Feature is?.. [15:37]GlenD: its really mostly clean code [15:37]GlenD: and a good place to put the common stuff for tls [15:38]dims: :) ok. [15:53]GlenD: ok never mind :) [15:53]GlenD: I think we just came to the conclusion that it's actually useful to have different abstract Receiver types [15:54]GlenD: because they're the ones that know the logic for message processing [15:54]GlenD: if you had an in/in/out MR, for instance, it could have processMessage1() and processMessage2() abstract operations [15:54]GlenD: that's nicer than just relying on a single invokeBusinessLogic(OperationContext), I think [15:56]GlenD: So the idea is to coalesce the TCCL stuff and the CurrentContext stuff into a setupThreadContext() and removeThreadContext() on AbstractMessageReceiver [15:57]GlenD: so developers of new MRs that want TLS functionality would need to know to call that
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
IMO this should be a blocker for 1.1 David On 24/09/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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=falsetrue/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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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=falsetrue/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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
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=falsetrue/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).
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: 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=falsetrue/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
