Hi Michelle, Unless I'm not right, I think you might be wrong : )
Application Scope will create 1 instance...similar to using a singleton class. In this case, you should avoid using any stateful instance variables outside the method itself. You might be thinking of "request" level scope in which case a new instance of the class is created for each request to the web service. Hope this helps.. -- Scott -----Original Message----- From: Michele Mazzucco [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 10:28 AM To: [email protected] Subject: Re: [Axis2] Stateful services question Hi all, If I'm right the application scope allows me to build steteful web services since there is only one service instance. What happens if several invocations happen concurrently? Only one passes through (and all others wait) or several threads run concurrently, possibly changing the service state altogether? If the last option applies, what happens if the state is saved into the service context? Is it synchronized in any way? Thanks in advance, Michele Deepal Jayasinghe wrote: > You have to add a attribute called "scope" into your service element , > as an example if you want to deploy your service in application scope , > then you can do that by just changing your service element as follows > <service name="foo" scope="application"> > ....... > </service> > > Michele Mazzucco wrote: > >> Hi Deepal, >> >> what do you mean as "scope" and how can I configure my service scope? >> >> Thanks, >> Michele >> >> Deepal Jayasinghe wrote: >> >> >>> Hi Michele; >>> First that depend on the scope that your service going to deploy , lets >>> say your session scope is application then you can store state in >>> service context coz there will be only one service context for that service. >>> >>> If the scope is SOAPSession then you can get into the same session by >>> sending serviceGroupID , so as loan as clients send the service group >>> id they can stay in one session, and you can keep state in either >>> service group context or service context. >>> >>> Or else you can store your service state in configuration context , that >>> is not the recommended way but you can still do that. >>> >>> Michele Mazzucco wrote: >>> >>> >>> >>>> Hi all, >>>> >>>> how can I maintain the service state across different client invocations >>>> (other than through static fields)? >>>> >>>> >>>> Thanks in advance, >>>> Michele >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
