axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <>
Subject [jira] Resolved: (AXIS2-3387) destroy(SvcCtx) is never invoked when service deployed in request session scope
Date Mon, 07 Jul 2008 11:49:32 GMT


Deepal Jayasinghe resolved AXIS2-3387.

    Resolution: Fixed

Unfortunately thats how I have implemented the session support for request scope :( 

> destroy(SvcCtx) is never invoked when service deployed in request session scope
> -------------------------------------------------------------------------------
>                 Key: AXIS2-3387
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.3, 1.2
>            Reporter: Mario A. Rodriguez
> My service implementation class contains the following method signatures:
> 	public void init(ServiceContext context)
> 	{
> 		System.out.println("init called");
> 	}
> 	public void destroy(ServiceContext context)
> 	{
> 		System.out.println("destroy called");
> 	}
> The service is then deployed using the default "request" scope.
> When I invoke the service the init() method is always invoked, but the destroy() method
is never called. If I understand the doc correctly the destroy() method should be invoked
after the operation completes, or perhaps I'm mistaken?
> If I change the session scope to "soapsession" then the destroy() method is actually
invoked. Although it doesn't appear to be invoked automatically after the 30 second timeout,
it waits until another request arrives and then clears out any sessions older than 30 seconds.
> My service implementation acquires a number of resources in the init() method and I was
hoping to rely on the calls to destroy() in order to free those resources, preferably after
completion of every request. The next best option would have been to use a short timeout for
the SOAP session, but it looks like neither session scope is able to provide a deterministic
way to free resources.
> Any suggestions would be appreciated.
> Thanks.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message