Pool of DAO's

[Omar Al Kababji]

Hi, i was wondering if someone ever thought about using a pool of DAO's i didn't found any framework that use something like this, my idea is simple since you know that your application will have for example 20 connections to the DB and you have only one DAO why should you need to use more than 20 instances of the DAO ?

from this i have created a DAOPoolManager class that will create a specified number of DAO's which can be configured by the user, and then all access to the DB will be done by obtaining a DAO from the Pool and using it and when you are done with the DAO you just free it, marking it that its free. the when there is a request for a DAO the PoolManger will search for a DAO instance that is marked as free if it dosen't find one it will send back the DAO with least users, as an example suppose the pool is of size 2

1) DAO1, DAO2 are free
2) a thread requests for a DAO and the PoolManager sends back DAO1 since its free and puts its (counter = 1)
3) another thread request for DAO and the PoolManger sends DAO2 back since DAO1 is busy since its counter value is 1, and increments DAO2.counter to 1
4) another thread request for a DAO and the PoolManger dosen't find a free DAO so it returns DAO1, however the thread will be forced to wait since DAO1 is currently busy
... and so on.


the idea suppose there are 10000 users and each makes a request why have 10000 DAOs when you really have only 20 DB connections, if you don't have the PoolDAO you will get 10000 DAO instances, however if you have a Pool of DAO's only 20 will be used and those twenty will keep being reused.


I have implemented all the logic above and its really working, what do you think about this? do see a real benefit ?


thanks in advance

(peace)

[Omar Al Kababji]

not even one opninion ...

[Bauke Scholtz]

What's the problem of having more than one instance of the same DAO class? The only problem which I can see is that it might eat memory (only a few bytes), but really nothing more than that. If an instance is eligible for GC, it will just be GC'ed.

At any way, you could just declare it as a (static) instance variable of the business class so that you don't need to (re)create it everytime or so.

[Omar Al Kababji]

The idea is that instead of the overhead of creating objects and then garbege collecting them you just create them once during the life time of your application. which leads also that you have more control over the memory. ofcourse if the web application will be used by 100 users there will be no benefit. but if its used by a huge quantity of users i think there would be a benefit ;)

[Bauke Scholtz]

Then just create one instance during application's lifetime? In terms of JSP/Servlet I usually declare the DAO class as an instance variable of the involved servlet. A servlet is created only once during application's lifetime. It works fine. I at least don't see any notable benefit of having a DAO pool.

[Omar Al Kababji]

but if you declare your DAO as an instance member of your servlet then threads running the servlet service() method will be fighting on that DAO.

[Bauke Scholtz]

Fighting? Java is multithreaded. Multiple threads can access the same method at once.

[Omar Al Kababji]

hehe yes but instead of accessing only one DAO you access n DAO's anyway i will be testing the idea in the web applications i will developer these days ;)

[Ilja Preuss]

omar al kababji wrote:hehe yes but instead of accessing only one DAO you access n DAO's anyway i will be testing the idea in the web applications i will developer these days ;)

I'm not sure what you are saying here.

Anyway, both creating just one DAO and creating as many DAOs as you want shouldn't be any problem. Object creation and garbage collection are very unlikely to be any problem in modern Java, especially if we are talking about such low numbers as just a few thousands of objects.

[Omar Al Kababji]

what i meant is that instead to make all your calls to only one DAO with its method synchronized, you make all your calls to a specific number of DAO's which would be generally adequate to the number of connections you can have to your DB. so that performance would increase and memory footprint would decrease. eliminating unnecessary operations of object initialization and garbaging those objects.


mmm may be you are right, but sometimes saving memory as much as possible is not a bad thing to do. don't you think so ?

[Ilja Preuss]

omar al kababji wrote:what i meant is that instead to make all your calls to only one DAO with its method synchronized

Why would you need to synchronize those methods?

so that performance would increase and memory footprint would decrease. eliminating unnecessary operations of object initialization and garbaging those objects.

mmm may be you are right, but sometimes saving memory as much as possible is not a bad thing to do. don't you think so ?

No.

First, often saving memory actually is in conflict with improving performance. Second, improving performance and saving memory need to be balanced with at least implementing functionality and having a simple, maintainable system.

Implementing your "solution" will cost time and increase the complexity of the system. The latter will both increase the probability of bugs and the cost of changes to the system. And that without knowing whether you actually have a problem that needs to be solved.

So, I would strongly advice to implement the simple solution (either one DAO or an unlimited amount of DAOs) first, and see whether it really proves to be a bottleneck. It's quite likely that it never will be - and if it is, you have much more data to come up with a good solution to the actual problem.

[mih ira]

hi all,

Any one know about a "PA BX Call Billing System" please let me know.
I have to develop it by using java and it should be a real time office call billing system.
[email protected] is my mail address
thanks

[Omar Al Kababji]

Why would you need to synchronize those methods?

in my case because the DAO's will be shared by all the parts of the application so synchronization will be needed in order to prevent concurrency problems. in a normal case there would be no problem for synchronization.

First, often saving memory actually is in conflict with improving performance. Second, improving performance and saving memory need to be balanced with at least implementing functionality and having a simple, maintainable system.

Yes you are right but when we talk about DAO's we are talking about objects that connect to a DB connection, and those connections are limited so why creating 10000 DAO's when you only have 20 connections ? at the end there will be only 20 DAO's capable of using those 20 connections at a time, so the rest of DAO's we sit there fighting for a free connection, so why even creating them ? and why wasting CPU time creating and then garbage them. may be its not that time consuming but for me every piece of byte saved is good, (Von Neumann would be happy to hear that )

Implementing your "solution" will cost time and increase the complexity of the system. The latter will both increase the probability of bugs and the cost of changes to the system.

I agree on a bit of more complexity but once is done it would be easy to reuse it in other projects, for the possible bugs I have implemented the code in such a way that if any exception could be caused by using the Pool of DAO's it will fallback to the ordinary way which is create a new DAO and send it back, i put an assertion on that piece of code because i have a strong bielive that it will never happens, (never say never anyway ;)). In addition there is a configuration that could turn off the pool where the Pool Manager would be sending back normal DAO's as if they where created manually using the constructor.


this is all for now i will be posting more information about it during my testing and debugging ;)

thanks.

[Bauke Scholtz]

omar al kababji wrote:in my case because the DAO's will be shared by all the parts of the application so synchronization will be needed in order to prevent concurrency problems. in a normal case there would be no problem for synchronization.

Still then, I don't see any benefit added by synchronization. It would only slow down things. A decent DB itself can perfectly handle concurrent queries.

Yes you are right but when we talk about DAO's we are talking about objects that connect to a DB connection, and those connections are limited so why creating 10000 DAO's when you only have 20 connections ? at the end there will be only 20 DAO's capable of using those 20 connections at a time, so the rest of DAO's we sit there fighting for a free connection, so why even creating them ? and why wasting CPU time creating and then garbage them. may be its not that time consuming but for me every piece of byte saved is good, (Von Neumann would be happy to hear that )

Still, your concern makes not much sense. A simple Java class like a DAO class is not an expensive resource as a database connection. Creating may cost 1ms. Garbaging may cost 1ms. Maybe less. Not worth a pool. Connecting may cost several hundred ms. There is fairly limited amount of connections available. That is certainly worth a pool.

I agree on a bit of more complexity but once is done it would be easy to reuse it in other projects, for the possible bugs I have implemented the code in such a way that if any exception could be caused by using the Pool of DAO's it will fallback to the ordinary way which is create a new DAO and send it back, i put an assertion on that piece of code because i have a strong bielive that it will never happens, (never say never anyway ;)). In addition there is a configuration that could turn off the pool where the Pool Manager would be sending back normal DAO's as if they where created manually using the constructor.

Uhm, I am not sure if I get you. But still, I don't see any benefit of a "DAO pool". What's next? A "Java class pool"? A "singleton"? No, thanks.

[Omar Al Kababji]

Thanks for your replay:

Still then, I don't see any benefit added by synchronization. It would only slow down things. A decent DB itself can perfectly handle concurrent queries. 

actually its the problem of the programmer to decide whether he will have to specify wether the code of his DAO should be synchronized or not, but if there are writing operation synchronization for sure will be need.

Still, your concern makes not much sense. A simple Java class like a DAO class is not an expensive resource as a database connection. Creating may cost 1ms. Garbaging may cost 1ms. Maybe less. Not worth a pool. Connecting may cost several hundred ms. There is fairly limited amount of connections available. That is certainly worth a pool. 

1ms * 1000 DAO = 1s may be you look at it as a small amount but for a server its an infinite time, and yes connecting would take more time and this would be only once during the life time of the application.


anyway i will provide results

[Heath Lilley]

Java application servers such as WebSphere have components designed to handle multiple requests and the caching of database connections. RDBMS like Oracle have components designed for optimized data access and data caching. These things can be used together to provide a way for you to access the database as you need to while minimizing the overhead of such operations.

These components are some of the reasons why the software costs so much. For the most part they follow industry standards so that when I write code to utilize them my code can be moved from product/environment to product/environment (in theory anyway). But if I write my own components to do the same thing then I would break those standards thus writing a custom architecture that only I know.

These components are provided so that I can focus on business logic which is what I get payed to do.

So unless you are just looking for a programming diversion it is a really bad idea to try and recreate these things yourself.