Object Pool Design Pattern

The Object Pool Design Pattern is a creational design pattern that manages a pool of reusable objects to minimize the overhead of creating and destroying objects. It maintains a collection of initialized objects and provides mechanisms for clients to efficiently borrow and return objects from the pool.

What is an Object Pool Design Pattern?

By managing a pool of reusable objects, the Object Pool design pattern lowers the overhead related to object generation and destruction. Clients can borrow items from the pool as needed and return them when finished using this pattern, which creates and maintains an object pool.

• An Object pool is a container that contains some amount of objects.
• So, when an object is taken from the pool, it is not available in the pool until it is put back.

What is the Object Pool Life Cycle?

The lifecycle of objects in an object pool involves the following stages:

• Stage 1: Creation: Objects are initially created and added to the pool.
• Stage 2: Borrowing: Clients request and borrow objects from the pool.
• Stage 3: Usage: Clients use the borrowed objects for their tasks.
• Stage 4: Returning: After usage, clients return the objects to the pool for reuse.
• Stage 5: Rejection or Destruction: If the pool is full or objects are not used, they may be rejected or removed from the pool.

Components and UML Diagram of Object Pool Design Pattern

Below are the main components of object pool design pattern:

• Client : This is the class that uses an object of the PooledObject type.
• ReuseablePool: The PooledObject class is the type that is expensive or slow to instantiate, or that has limited availability, so is to be held in the object pool.
• ObjectPool : The Pool class is the most important class in the object pool design pattern. ObjectPool maintains a list of available objects and a collection of objects that have already been requested from the pool.

Real-World Example of Object Pool Design Pattern

Real-world example for the Object Pool design pattern could be a library or a bookstore.

1. Book Inventory:
   • Think of the library's collection or the bookstore's inventory as the pool of objects.
   • Each book represents an object that can be borrowed or used.
2. Borrowing Books:
   • Customers go to the librarian or the store clerk to borrow a book from the library or bookstore.
   • Similarly, in software, a component will ask the object pool for an object when it requires one.
3. Available Books:
   • The library or bookstore keeps track of available books that haven't been borrowed yet.
   • These books are ready to be loaned out. Similarly, in the object pool, there are objects that are available for use.
4. Borrowing Process:
   • A customer or patron checks out a book from the collection when they wish to borrow it.
   • This action is analogous to a component taking an object from the object pool.
5. Returning Books:
   • The consumer or patron returns the book to the library or bookstore after reading or using it.
   • Similarly, in software, when a component finishes using an object, it returns it to the object pool.
6. Book Condition:
   • On a regular basis, the library or bookstore inspects the books, fixes any damage, and removes any that are in bad shape out of circulation.
   • This maintenance process is similar to the validation and cleanup procedures performed on objects in the object pool.
7. Maximum Book Inventory:
   • Due to financial or space limits, both the library and the bookstore are limited in how many books they can keep.
   • Similarly, in software, object pools often have a maximum size to prevent resource exhaustion.

Example Implementation of Object Pool Design Pattern

Problem Statement:

Let's take the example of the database connections. It's obviously that opening too many connections might affect the performance for several reasons: 

• Creating a connection is an expensive operation.
• When there are too many connections opened it takes longer to create a new one and the database server will become overloaded.

Here the object pool manages the connections and provide a way to reuse and share them. It can also limit the maximum number of objects that can be created. Let's see component wise code:

1. Reusable Pool(PooledObject)

import java.sql.Connection;
import java.sql.SQLException;

// This class represents the objects that are expensive to create or have limited availability
public class PooledObject {
    private Connection connection;

    public PooledObject(Connection connection) {
        this.connection = connection;
    }

    public Connection getConnection() {
        return connection;
    }

    public void close() {
        try {
            connection.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    public boolean isClosed() {
        try {
            return connection.isClosed();
        } catch (SQLException e) {
            e.printStackTrace();
            return true;
        }
    }
}

2. Object Pool

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;
import java.util.Hashtable;

// ObjectPool class maintains a list of available objects and a collection of objects that have already been requested from the pool
public abstract class ObjectPool<T> {
    private long deadTime;
    private Hashtable<T, Long> lock, unlock;

    public ObjectPool() {
        deadTime = 50000; // 50 seconds
        lock = new Hashtable<>();
        unlock = new Hashtable<>();
    }

    abstract T create();

    abstract boolean validate(T o);

    abstract void dead(T o);

    public synchronized T takeOut() {
        long now = System.currentTimeMillis();
        T t;
        if (unlock.size() > 0) {
            Enumeration<T> e = unlock.keys();
            while (e.hasMoreElements()) {
                t = e.nextElement();
                if ((now - unlock.get(t)) > deadTime) {
                    unlock.remove(t);
                    dead(t);
                    t = null;
                } else {
                    if (validate(t)) {
                        unlock.remove(t);
                        lock.put(t, now);
                        return t;
                    } else {
                        unlock.remove(t);
                        dead(t);
                        t = null;
                    }
                }
            }
        }
        t = create();
        lock.put(t, now);
        return t;
    }

    public synchronized void takeIn(T t) {
        lock.remove(t);
        unlock.put(t, System.currentTimeMillis());
    }
}

3. Client

import java.sql.Connection;

// Client class that uses an object of the PooledObject type
public class Client {
    public static void main(String[] args) {
        // Create the ConnectionPool:
        JDBCConnectionPool pool = new JDBCConnectionPool(
                "org.hsqldb.jdbcDriver", "jdbc:hsqldb: //localhost/mydb",
                "sa", "password");

        // Get a connection:
        Connection con = pool.takeOut();
        // Return the connection:
        pool.takeIn(con);
    }
}

Complete code for the above example

Below is the complete code of the above example:

// Java program to illustrate 
// Object Pool Design Pattern 
abstract class ObjectPool<T> { 
    long deadTime; 

    Hashtable<T, Long> lock, unlock; 

    ObjectPool() 
    { 
        deadTime = 50000; // 50 seconds 
        lock = new Hashtable<T, Long>(); 
        unlock = new Hashtable<T, Long>(); 
    } 

    abstract T create(); 

    abstract boolean validate(T o); 

    abstract void dead(T o); 

    synchronized T takeOut() 
    { 
        long now = System.currentTimeMillis(); 
        T t; 
        if (unlock.size() > 0) { 
            Enumeration<T> e = unlock.keys(); 
            while (e.hasMoreElements()) { 
                t = e.nextElement(); 
                if ((now - unlock.get(t)) > deadTime) { 
                    // object has dead
                    unlock.remove(t); 
                    dead(t); 
                    t = null; 
                } 
                else { 
                    if (validate(t)) { 
                        unlock.remove(t); 
                        lock.put(t, now); 
                        return (t); 
                    } 
                    else { 
                        // object failed validation 
                        unlock.remove(t); 
                        dead(t); 
                        t = null; 
                    } 
                } 
            } 
        } 
        // no objects available, create a new one 
        t = create(); 
        lock.put(t, now); 
        return (t); 
    } 
    synchronized void takeIn(T t) 
    { 
        lock.remove(t); 
        unlock.put(t, System.currentTimeMillis()); 
    } 
} 

// Three methods are abstract 
// and therefore must be implemented by the subclass 

class JDBCConnectionPool extends ObjectPool<Connection> { 
    String dsn, usr, pwd; 

    JDBCConnectionPool(String driver, String dsn, String usr, String pwd) 
    { 
        super(); 
        try { 
            Class.forName(driver).newInstance(); 
        } 
        catch (Exception e) { 
            e.printStackTrace(); 
        } 
        this.dsn = dsn; 
        this.usr = usr; 
        this.pwd = pwd; 
    } 

    Connection create() 
    { 
        try { 
            return (DriverManager.getConnection(dsn, usr, pwd)); 
        } 
        catch (SQLException e) { 
            e.printStackTrace(); 
            return (null); 
        } 
    } 

    void dead(Connection o) 
    { 
        try { 
            ((Connection)o).close(); 
        } 
        catch (SQLException e) { 
            e.printStackTrace(); 
        } 
    } 

    boolean validate(Connection o) 
    { 
        try { 
            return (!((Connection)o).isClosed()); 
        } 
        catch (SQLException e) { 
            e.printStackTrace(); 
            return (false); 
        } 
    } 
} 

class Main { 
    public static void main(String args[]) 
    { 
        // Create the ConnectionPool: 
        JDBCConnectionPool pool = new JDBCConnectionPool( 
            "org.hsqldb.jdbcDriver", "jdbc:hsqldb: //localhost/mydb", 
            "sa", "password"); 

        // Get a connection: 
        Connection con = pool.takeOut(); 
        // Return the connection: 
        pool.takeIn(con); 
    } 
} 

When to Use Object Pool Design Pattern?

Below is when to use object pool design pattern:

• Expensive Object Creation: Pooling can be useful when producing instances of objects that require a lot of resources, like building heavyweight objects or database or network connections. You can make these expensive objects once and utilize them repeatedly due to pooling.
• Limited Resource Availability: When there's a limited availability of resources, such as a limited number of database connections, pooling helps in efficiently managing those resources by reusing them rather than creating new ones beyond the limit.
• Reducing Overhead: Object creation and destruction overhead can be significant in certain applications. By reusing objects from the pool, you can reduce the overhead associated with creating and destroying objects frequently.
• Improving Performance: Pooling can lead to improved performance by avoiding the overhead of object creation and destruction and by reducing contention for limited resources.

When not to Use Object Pool Design Pattern?

Below is when not to use object pool design pattern:

• Lightweight Objects: Using an object pool could add unnecessary complexity without providing many advantages if objects are easy to produce and destroy and the overhead of object generation is minimal.
• No Resource Scarcity: Implementing an object pool might not be required and could introduce needless complexity if the system has an abundance of resources and there is no chance of resource exhaustion.
• Unpredictable Usage Patterns: Implementing an object pool may not be advantageous if the usage pattern of the objects is so unexpected that they are rarely reused or if it is impossible to estimate the pool size.
• Maintenance Overhead: Object pools introduce additional complexity to manage the lifecycle of objects, such as handling object creation, validation, and destruction. If the maintenance overhead outweighs the benefits gained from pooling, it might not be worth implementing.