Connection Pools and Resources.

As 'contract scum', I've often worked with a lot of client's implementations of database connection pools.

They all have one thing in common, they all wrap the underlying java.sql.Connection implementation with their own connection-pool-aware version, and fail to truly meet the contract of the interface.

The problem comes where they override the behaviour of the close() method, to implement the connection pool behaviour, the override returns the connection to the pool.

Spot the obvious error here.

Go on, if you can you'll be streets ahead of all the really experienced people that implement these things.

Think about what happens to a non-pooled collection when the close() method is called. The outstanding transaction is either committed or rolled-back, and all open resources are released.

These behaviours are what are missed by many custom-rolled connection pool implementations.

The results are various:

• Either an experienced developer will write a lot of boiler place catch and finally blocks to close resources.
• Or an inexperienced developer will generate memory leaks left, right and center.
• Connections may be returned to the pool in an inconsistent transactional state.

I dream of the day when these connection pool implementations are replaced by complete implementations and I no longer have to scatter catch and finally blocks across my code.