There are already such classes, pre-written, pre-debugged, and someone else is paying most of the time and expense of upkeep. One popular example is the Apache dbcp (Database Connection Pool), which is the default pooler for Tomcat, although I've also used it in stand-alone (non-web) applications.
Customer surveys are for companies who didn't pay proper attention to begin with.
This isn't really a performance issue, but a design issue.
From a design standpoint database access code should be kept in one or at least in as few classes as possible. I wouldn't code it as a singleton as that isn't as flexible. You could certainly have static data structures that make the class similar to a singleton. Even if you use open source data access classes I would try to hide them in my own data access classes. This allows you to swap out that implementation if needed.
steve souza wrote:This isn't really a performance issue, but a design issue.
... Even if you use open source data access classes I would try to hide them in my own data access classes. This allows you to swap out that implementation if needed.
That brings up a good point. When you use a popular off-the-shelf product like apache jdbc it's also likely been optimized over its lifespan as well.
You don't really need to design "hiding" (a/k/a abstraction) classes for JDBC connection pools, however. The JDBC specs also define that particular mechanism (DataSource).
In the cases I've mentioned where I used Apache JDBC, the app was also using Spring, and since the abstracting mechanisms are already defined in and place, I used Spring to simply wire the database connection pooler into JPA with no custom code required at all.
Inside Hibernate , Since the creation of SessionFactory is expensive , is it good to mention this as a Singleton class so that we can get the same instance ?? and also will it not be a bottleneck for the Application ??
Is it good to have this class as a Singleton or not ??
subject: Singleton class for Closing Database Connections .