Java Design Patterns – Is Storing the Connection Pool in a Singleton a Bad Practice?

design-patternsjava

I just read this question and the answer claims:

"Lets assume db connection object is singleton in my application"

This is a must not. Your database connection MUST NEVER BE (yes, bolded and
with capitals to make sure you and every reader never make this
mistake) a singleton object. Your Connection con MUST NOT be part of a
singleton to keep it open all the time. Instead, use a proper database
connection pool that will take care of opening the necessary physical
database connections and keep them alive through the live of your
application.

We of course use a connection pool to take care of our, well, connections. Still, we store this pool in a singleton. How else would one ensure that it lives throughout the application? Ist his bad practice?

Best Answer

I think the quoted answer is mainly stating an opinion.

The one fact in that answer is about the "per classloader" aspect.

In other words: unless you are in a situation, where that "multiple classloaders" part comes in there are no technical reasons to not use a singleton.

Of course, the key element would be to implement a "correct" singleton; for example by using a Java enum for that.

Related Solutions

Java Best Practices – Is It Bad Practice to Create New Objects Without Storing Them?

There's an element of personal preference to this, but I think that not storing the reference is not necessarily a bad practice.

Consider the following hypothetical example:

new SingleFileProcessor().process(file);

If a new processor object needs to be created for every file, and is not needed after the process() call, there's no point in storing a reference to it.

Here is another example, taken from the Java concurrency tutorial:

(new HelloThread()).start();

I've seen lots of other examples when the reference is not stored, and that read perfectly fine to my eye, such as:

String str = new StringBuilder().append(x).append(y).append(z).toString();

(The StringBuilder object is not kept.)

There are similar patterns involving common.lang's HashCodeBuilder et al.

DAO/Webservice Consumption in Web Application – Best Practices

The options you've provided lead me to think that continuing to use the SSIS jobs to import data into a database you control for your application looks to be the best option for both managing the data flow and performance for the end-user.

If you've got requirements that need more up to date data than that supplied via SSIS then I would go for using the web services at that point for those specific parts of the application.

There is nothing in the DAO pattern that requires the implementation to be a singleton, you'll have a much easier time testing the DAO classes if they are implemented as normal classes and then only use a single instances as a dependency when in production.

Finally as session maintenance is required i would use short lived instances given you need to maintain per-request and if connection/resource limits are required to be managed a resource pool pattern implementation could be used to manage checking out/in access to instances that maintain the session tokens (eg get a new token on check out, release token on check in, ensure use is short lived). There should be a number of existing resource pool implementations available, use one as there are many gotchas to implementing that type of pattern.

Best Answer

Related Solutions

Java Best Practices – Is It Bad Practice to Create New Objects Without Storing Them?

DAO/Webservice Consumption in Web Application – Best Practices

Related Topic