Object cesspool

An object pool is a set of initialized objects that can be used and reused by clients rather than having to create and destroy objects every time. A client can request an object from the pool, use it and then return it. Object pool is a design pattern.

Object pooling can increase performance when object instantiation is expensive, common and there are few objects in use at any one time. It is therefore often used for database of socket connections. However, in some cases object pooling can decrease performance.

Object cesspool is an anti-pattern which occurs when the state of the objects returned to the pool is not reset. If another client is then given the object whose state has not been reset, this can lead to bugs and program crashes.

It is particularly important to reset the fields of an object that have a significant influence on the behavior of the object.

Example

Imagine that we are writing a website which people can connect to using a web browser. Our web application needs to manage the incoming client connections and store the state of a client's session using the Session class. Because these sessions are expensive to instantiate, we use an object pool. Every time a client connects to the website, they are assigned a Session variable from the object pool. When they leave our site, the Session object is returned to the pool.

Our Session object may store information about the login status of the user and their history. If we do not remove this information from the object before returning it to the pool (for example set the login status back to not logged in) this will cause strange behavior when the object is reused by another client.

Liabilities

• Strange behavior and bugs if parts of the object that are important for the behavior of the object are not reset.

See also

• Flyweight pattern is a pattern that uses an object pool (and a strategy for avoiding it becoming a cesspool).