Problem - Thread Pool?

[Bhavin Sanghani]

Following question was asked to me in one F2F interview :

We are using one third party library and there is one call e.g. doUpdate() which performs operations like open connection, network calls, close connection. This method has one constraint. If connection goes above 20 then it will throw an error of MAX_CONN_EXCEED. As this is third party library, we can not really change the source code. Also, we dont want to spend money to buy more licenses which can allow more connections.

The question is:
How can we handle this scenario in our code so, we can manage n number of requests using this library and need not to buy separate licenses??

I thought of Thread Pool but not sure whether this is a solution. Also, not sure if that is an answer then how to implement it.

Can anybody guide me on this?

Thanks,
Bhavin

[ May 24, 2008: Message edited by: Bhavin Sanghani ]
[ May 26, 2008: Message edited by: Bhavin Sanghani ]

[Henry Wong]

I thought of Thread Pool but not sure whether this is a solution. Also, not sure if that is an answer then how to implement it.

Well, do you know what a thread pool is good for? And why is it used? If you do, then you should know whether you can develop a solution with it or not.

Henry

[Bhavin Sanghani]

Well, do you know what a thread pool is good for? And why is it used? If you do, then you should know whether you can develop a solution with it or not.

Not really! I have conceptual knowledge of Thread Pool. My thought process was:

- Maximum 20 connections are allowed
- We need to avoid the error
- Full-fill incoming client request

So, why don't we create Thread Pool and block the request for time being if simultaneous request is more than 20. I know using Thread Pool atleast you can save time in creating new threads...

Do you think this is the right direction? Let me know if you have any other suggestion.
[ May 24, 2008: Message edited by: Bhavin Sanghani ]

[Gabriel Claramunt]

One of the applications of the singleton pattern is to control access to limited resources. You can hide the service inside the singleton class and control that no more than 20 instances are created.

[Nitesh Kant]

What you need is a connection pool and not a thread pool.
Using the connection pool(somewhat similar to what Gabriel has suggested) you can limit the number of connections.
There is enough literature available on net telling how to implement a connection pool.

[Adeel Ansari]

I don't think its about thread pool or connection pool, or whatever at this point. First thing, you must do is to adapt it, may be using adapter pattern. Find out how and where it is applying this constraint, after that you can adapt that in your own code by giving a new implementation. Then you can use connection pool for a better performance.

I hope this would clear the thing. Since, before proceeding in any direction you need to adapt it, there is no other work around, if that API doesn't give you any public mutator to modify that constraint.

The other hack might be to use reflection to set the maximum no. of connections allowed. But I would prefer the former. Because its the right way. Further, it will give you more flexibility, you can implement it as you like, and then you can change it in future according to your requirements.

Cheers.

[Jim Yingst]

If there's a way to insert a connection pool into the existing code, that would be great. (Does it accept a DataSource for example?) But it may be that's not really possible. In that case, the simplest thing is probably to use a java.util.concurrent.Semaphore, and wrap all calls to the DB with acquire() and release():

public class DbProtector {
    private static final Semaphore dbSemaphore - new Semaphore(MAX_DB_CONNECTIONS, true);
 
    public static Foo findFoo(int key) {
        dbSemaphhore.acquire();
        try { return ThirdParyClass.findFoo(key); }
        finally { dbSemaphore().release(); }
    }
 
    public static int insertFoo(Foo foo) {
        dbSemaphhore.acquire();
        try { return ThirdParyClass.insertFoo(foo); }
        finally { dbSemaphore().release(); }
    }
 
    ...
}

For every ThirdPartyClass method you need to access, write a new method inthis DbProtector class that puts an acquire() in front, and a release() inside a finally. That way, calls to ThirdPartyClass will block if there are more than MAX_DB_CONNECTIONS calls still active. Then, all other classes should use DbProtector, not ThirdPartyClass.

Here for simplicity I'm assuming that all methods are static. You can adapt this as necessary, depending what instance methods there are, and how they're instantiated. You might consider having DbProtector extend ThirdParty class, overriding each instance method with a version that uses the semaphore.
[ May 27, 2008: Message edited by: Jim Yingst ]

[Adeel Ansari]

The example shown is a bit like Decorator. And when we make it a sub-class, or use composition, it would turn into an Adapter, if I am not mistaken.

Thanks Jim, I have never looked into this Semaphore class.