You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org> on 2006/09/24 13:34:23 UTC
[jira] Created: (AXIS2-1224) setOperationContext() not thread-safe
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-1224) setOperationContext() not thread-safe
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=all ]
Davanum Srinivas reassigned AXIS2-1224:
---------------------------------------
Assignee: Deepal Jayasinghe
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12439728 ]
Deepal Jayasinghe commented on AXIS2-1224:
------------------------------------------
Hmm , well when you deploy a service in application scope there will be only one instance of the service impl class so it wont be thread safe at all. The only solution is to store all the relevant properties and parameters in the service context , since there is only one service context for lifetime of the service.
So , when you deploy a service in application scope Axis2 can not make setOperationContext thread safe. In all the other scope it will be thread safe most of the time.
I think I will not be able to fix this issue.
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12437199 ]
Christopher Sahnwaldt commented on AXIS2-1224:
----------------------------------------------
Here is an example of a user implementing setOperationContext in exactly this non-thread-safe way:
http://www.mail-archive.com/axis-dev@ws.apache.org/msg21142.html
The instance variable carsDB seems to be set in setOperationContext():
carsDB = (CarsDB)servletCtx.getAttribute("carsCB");
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12439698 ]
Davanum Srinivas commented on AXIS2-1224:
-----------------------------------------
Deepal,
Thoughts?
-- dims
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Derek Foster (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12440288 ]
Derek Foster commented on AXIS2-1224:
-------------------------------------
You could have MessageContext hold all of its data in ThreadLocal variables... That way, no user code would have to change.
If MessageContext is implemented by Axis code directly, then instead a Proxy object implementing a MessageContext interface could hold a reference to the "real" MessageContext object via a ThreadLocal variable, and could forward calls as necessary.
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12442258 ]
Davanum Srinivas commented on AXIS2-1224:
-----------------------------------------
Looks like we made some progress:
http://marc.theaimsgroup.com/?l=axis-cvs&m=116076209719995&w=2
http://marc.theaimsgroup.com/?l=axis-cvs&m=116076213624677&w=2
-- dims
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12442327 ]
Davanum Srinivas commented on AXIS2-1224:
-----------------------------------------
Deepal,
Just reviewed the code, MessageContext.getCurrentContext() should and will work whatever the ServiceTCCL is set to (or even if it is not set). Let's keep it this way as it is in SVN.
thanks,
dims
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-1224) setOperationContext() not thread-safe
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=all ]
Deepal Jayasinghe resolved AXIS2-1224.
--------------------------------------
Resolution: Fixed
We had to use the same solution that Axis 1 has used , that is we fixed the problem using TCL.
With this change if you want to access the message context inside the service impl class then you can achieve that using following two steps;
you need to add following parameter into services.xml
<parameter name="ServiceTCCL">XYZ</paramere>
XYZ can be either composite or service
Then you can call MessageConetext.getCurrentContext();
Note. MessgaeContext.getCurrentContext() only work inside service impl class .
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12440096 ]
Thilina Gunarathne commented on AXIS2-1224:
-------------------------------------------
Any reasons why do we need to have one instance of the service impl class throughout the service life...
IMO anybody can store whatever the state data needed through out the life of the service, in the ServiceContext...
Are there any special cases where we can't do that.. If there aren't any reasons let's create the service object per invocation , as we are doing in other cases....
> 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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Jeff Peterson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12437952 ]
Jeff Peterson commented on AXIS2-1224:
--------------------------------------
Correct me if im wrong, but the scope of the service object is limited to a single operation.
Check out getTheImplementationObject() in AbstractMessageReceiver.java (relevant snippet below).
ServiceContext serviceContext = msgContext.getOperationContext().getServiceContext();
Object serviceimpl = serviceContext.getProperty(ServiceContext.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
> Assigned To: Deepal Jayasinghe
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-1224) setOperationContext() not
thread-safe
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-1224?page=comments#action_12437201 ]
Christopher Sahnwaldt commented on AXIS2-1224:
----------------------------------------------
The issue has also been raised here
http://www.mail-archive.com/axis-dev@ws.apache.org/msg19379.html
and here
http://www.wso2.net/kb/106
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org