Lex Spoon writes:
 > Ragnar Hojland Espinosa <ragnar at linalco.com> wrote:
 > > The thing is.. I'm leaving behind lots open postgres connections which would
 > > be nicely closed with a "destructor", and right now I don't know how to
 > > automatically close (maybe you cant?) when it should (the sooner the
 > > better). Obviously, postgres complains quite loudly when you have too many
 > > open, and things suddely get very ugly.
 > Finalization works as well as it can, but unfortunately that isn't
 > wonderfully well.  For handling resources other than memory, e.g.
 > database connections, it is usually better if you can work out a way to
 > do it manually.

The idiom that popped up last time was:

	connectionPool withConnection: [:conn| do the work].

withConnection should get a new connection from the pool and also
return it to the pool. Be sure to use ensure: to make sure that the
connection is returned even if an exception occurs as Tim suggested
last time.

This at least gives you lexically scoped access to resources in a
sensibly scoped manner. That is what C++ finalisation really buys
you. 

There was a good discussion about using finalisation and why it's not
a good technique about a year ago. It started with a similar question
about database connection finalisation.

Bryce