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 |
> 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 |
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 |
Free forum by Nabble | Edit this page |