Thanks everyone for the responses. After reading the responses, and some testing I've confirmed that not specifying a scope in the service descriptor makes axis2 instantiate a new instance of our pojo service class with each new request. I've also since changed these variables, because there was no reason to have them as that scope.
Thanks! Chris -----Original Message----- From: java-user-return-83475-meeusen.christopher=mayo....@axis.apache.org [mailto:java-user-return-83475-meeusen.christopher=mayo....@axis.apache.org] On Behalf Of Stadelmann Josef Sent: Monday, September 13, 2010 8:03 AM To: [email protected]; [email protected] Subject: AW: Field level variables Christopher Jeff is correct; in service.xml there is scope="soapsession" This makes axis2 creating a new instance of your service class for each new user-session. For that your service class demands 3 more methods public void init(ServiceContext sCtx) throws XMLStreamException { . . . } public void destroy(ServiceContext sCtx) throws XMLStreamException { . . . } public void setOperationContext(OperationContext oCtx) { . . . } AND In axis2.xml at ./axis2/WEB-INF/conf you have to set-up ConfigContextTimeoutInterval to a much bigger value. The value is the TimeoutInterval in ms at which the users client has to send latest the next session-request to keep the service class instance (the service providing object a-life). This is what we understand as "LONG LASTING USER SESSIONMS" and with AXIS2-1.2 it works greate. <!--This will give out the timeout of the configuration contexts, in milliseconds--> <parameter name="ConfigContextTimeoutInterval">28800000</parameter> You can look to the TimeoutInterval as the life-time of your instance, after which destroy() gets called. This is true unless you the user-session places a next request before this TimeoutInterval ends; at which time the TimeoutInterval starts from 0. That is what we use with our SpezplaService and AXIS2-1.2 and I have no confirmation and did not yet test that the same is true for AXIS2-1.5.x Somewhere in the Oxygen-Tank Area there is a more precise document. Josef -----Ursprüngliche Nachricht----- Von: Jeff Greif [mailto:[email protected]] Gesendet: Freitag, 20. August 2010 18:03 An: Meeusen, Christopher W. Cc: [email protected]; [email protected] Betreff: Re: Field level variables This is configurable in the deployment descriptor. The <service> element has an attribute "scope". One allowed value of this attribute creates an instance of the implementing class for each invocation. Jeff On 8/20/2010 7:18 AM, Meeusen, Christopher W. wrote: > Let me try to ask this another way. Say I have a class MyService.java and > this class has a web service method in it. What does the lifecycle of this > class look like? Is there a new instance of MyService instantiated for each > request to one of the methods within it, or is one instance of this class > instantiated and multiple threads use the same instance of the class? > > -----Original Message----- > From: Meeusen, Christopher W. > Sent: Wednesday, August 18, 2010 5:45 PM > To: [email protected] > Cc: [email protected] > Subject: Re: Field level variables > > My main concern is if this is thread safe. Are pojos re entrant in axis2-1.3? > > On Aug 18, 2010, at 17:21, "Meeusen, Christopher W." > <[email protected] > wrote: > >> I’m looking through some of my colleagues code and I’m noticing some >> field level variables declared inside one of our pojos. Someth ing >> similar to this: >> >> >> >> Public class classA >> >> { >> >> private classB aClassb; >> >> >> >> Public classC[] aMethod() >> >> { >> >> aClassb= new classB(); >> >> } >> >> } >> >> >> >> aMethod() is exposed as a web service and is called several thousand >> times per minute. Is this thread safe? I know it is bad to have >> field level variables unless they are really needed but I don’t know >> if this behavior is ok inside of the axis2 environment. >> >> >> >> Thanks, >> >> Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
