Deepal,

thanks very much for your clarifications. Just the last question ;): is
it possible (and necessary) to configure modules the same way or only
one module instance is created?


Thanks in advance,
Michele

Deepal Jayasinghe wrote:
> Hi Michele;
> Yes , you can store states in service instance without having any
> problems . But if you store the state in service context external
> parties can access that good example could be a handler can change
> properties there in service context.
> 
> Michele Mazzucco wrote:
> 
>> Hi Deepal,
>>
>> ok, if I've well understood from [1], if the scope is set to
>> "application" then only one instance of the service exists. So why
>> should I store the system state into the service context and not into an
>> instance variable (remember that there is only one service instance, and
>> thus the instance variable should be maintained across service invocations).
>> Can you confirm my assumption, please?
>>
>> Thanks,
>> Michele
>>
>> [1] http://www.developer.com/open/article.php/10930_3589126_3
>>
>> 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]

Reply via email to