[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12437200 ] Christopher Sahnwaldt commented on AXIS2-1224: ----------------------------------------------
It *IS* possible to implement setOperationContext() in a thread-safe way: store data not in a normal instance variable, but in a ThreadLocal. But that is a somewhat advanced concept and may introduce other problems with thread pools and memory leaks. 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. > setOperationContext() not thread-safe > ------------------------------------- > > Key: AXIS2-1224 > URL: http://issues.apache.org/jira/browse/AXIS2-1224 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core, deployment > Affects Versions: 1.1 > Reporter: Christopher Sahnwaldt > Priority: Blocker > > If a service has application scope, one service object is created per > application. > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
