Ressource management

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Ressource management

Hans N Beck
Hi,

to seaside I'm certainly a beginner, and from this it is not clear to  
me what  rules there are for proper ressource management. I had the  
problem with ODBC connections, which were catched by WASessions (I  
think). Only a "Cache clean" killed the ODBC instances.
Where would be a good place to clean - up i.e. database connections ?

regards

Hans
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Ressource management

Bany, Michel
 

> to seaside I'm certainly a beginner, and from this it is not
> clear to me what  rules there are for proper ressource
> management. I had the problem with ODBC connections, which
> were catched by WASessions (I think). Only a "Cache clean"
> killed the ODBC instances.
> Where would be a good place to clean - up i.e. database connections ?


In one of my projects, we are using Seaside in VW for building a UI
for a service that is running on a mainframe. The communication between
the UI and the service is based upon socket  connections which are
managed
out of a pool. We have a mechanism for obtaining socket connections
from the pool and another one for releasing and cleaning them up. The
socket
connections are obtained lazily as needed and released as early as
possible
when no longer needed, to make sure that socket connections with the
mainframe are held as briefly as possible.

Although this is not database connections, these ideas may be reusable
in your case.

For robustness, we need to make sure that socket connections are
properly
released in all situations, so we have subclassed WASession and
re-implemented  
#responseForRequest: with something like this :

responseForRequest: aRequest
        [response := super responseForRequest: aRequest]
                ensure: [self releaseResourcesForRequest: aRequest
response: response].
        ^response.

We are not using #unregistered, since we are not holding any socket  
connection resource between HTTP requests.

For even more robustness (when something weird occurs while executing  
the ensure block above), we also subclassed WAProcessMonitor and
re-implemented
#terminate with something like this:

terminate
        | theProcess |
        (theProcess := process) ifNotNil:
                [theProcess terminate.
                self releaseResourcesForProcess: theProcess].

The WAProcessMonitor object is instantiated in the #initialize method  
of our WASession subclass

initialize
        super initialize.
        monitor := MyProcessMonitor new.

HTH
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Ressource management

Hans N Beck
Hi Michel,

thank you for the hints, they will be useful, I think :-)

Regards


Hans

Am 23.05.2006 um 15:40 schrieb Bany, Michel:

>
>
>> to seaside I'm certainly a beginner, and from this it is not
>> clear to me what  rules there are for proper ressource
>> management. I had the problem with ODBC connections, which
>> were catched by WASessions (I think). Only a "Cache clean"
>> killed the ODBC instances.
>> Where would be a good place to clean - up i.e. database connections ?
>
>
> In one of my projects, we are using Seaside in VW for building a UI
> for a service that is running on a mainframe. The communication  
> between
> the UI and the service is based upon socket  connections which are
> managed
> out of a pool. We have a mechanism for obtaining socket connections
> from the pool and another one for releasing and cleaning them up. The
> socket
> connections are obtained lazily as needed and released as early as
> possible
> when no longer needed, to make sure that socket connections with the
> mainframe are held as briefly as possible.
>
> Although this is not database connections, these ideas may be reusable
> in your case.
>
> For robustness, we need to make sure that socket connections are
> properly
> released in all situations, so we have subclassed WASession and
> re-implemented
> #responseForRequest: with something like this :
>
> responseForRequest: aRequest
> [response := super responseForRequest: aRequest]
> ensure: [self releaseResourcesForRequest: aRequest
> response: response].
> ^response.
>
> We are not using #unregistered, since we are not holding any socket
> connection resource between HTTP requests.
>
> For even more robustness (when something weird occurs while executing
> the ensure block above), we also subclassed WAProcessMonitor and
> re-implemented
> #terminate with something like this:
>
> terminate
> | theProcess |
> (theProcess := process) ifNotNil:
> [theProcess terminate.
> self releaseResourcesForProcess: theProcess].
>
> The WAProcessMonitor object is instantiated in the #initialize method
> of our WASession subclass
>
> initialize
> super initialize.
> monitor := MyProcessMonitor new.
>
> HTH
> Michel.
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside