So, to keep it short: as I recently published some code using database some suggested to me to use DataSource instead of DriverManager. I thought to give it a try and looked at some examples, but the only difference I found was on how the Connection object is created. Also I read some on Google that using DataSource is the preferred way of doing so. I guess this was already asked, but the didn't got me something useful.
What's the main advantage of using DatSource over DriverManager? Yes, I've read something about connection pooling and distributed transaction, but I don't use these.
In my code I have a single master server instance wich only uses one connection and all queries are synchronized. I can't see any advantage using DataSource. Maybe could give me some hint?
A DataSource uses DriverManaagers. A DataSource is an Enterprise Java interface that serves as a Connection Factory.
Webapp Servers, per the J2EE and JEE specs come with a connection pool mechanism (often, you can actually select from a number of plug-replaceable pool classes). The webapp uses JNDI to locate a DataSource, then uses the DataSource to return a Connection. When possible, the Connection it returns will come from its underlying Connection Pool.
The reason why Connection Pools (and therefore DataSources) are recommended in multi-user applications (such as webapps) is that when you use a DriverManager to obtain a Connection, it has to build the connection completely from scratch, including the fairly tedious job of opening a network connection to the database. A Connection Pool, on the other hand, recycles Connections. The actual Connection object that the DataSource returns is, in fact, a façade object, where the Connection close() method has been replaced by code that returns the Connection to the pool for re-use instead of simply destroying it like the "real" Connection would. So you don't have to create everything from scratch every time you need a connection.
You can use Connection Pools (and DataSources) outside of the webapp world as well, since there are stand-alone Connection Pool libraries available for your enjoyment. Apache has one that was the built-in default pool for the Tomcat webapp server for many years, in fact. Connection Pool objects are generally instantiated and managed as JavaBeans - in the case of webapp servers, the server itself handles those functions.
Regardless of how you obtain/manufacture a Connection, however, never attempt to store it as a session object in a web application. It's not Serializable, and in fact many webapp servers will refuse to let you store it. The ones that do will behave unpredictably. Instead, only get the Connection when you need it, and close it as soon as you no longer need it.
Science is the process of replacing what we "know" with what is TRUE. Politics, alas, often prefers to be the opposite.
Thanks so far, but I guess my field is way different than servlets and application servers.
In my case it's a centralized x509-certificate based authentication system. In fact, it doesn't matter how many users are connect to my service, as authentication and access privileges all managed by javas built-in ssl-stuff. The only thing I use the database for is to keep track of users, thier certificats, revocation-status (wich is used to create CRLs once each night) and contact-information plus some other stuff for identity automatic certificate re-newal. It's a management back-end only used by administrators. There is no user-interaction with it, cause there're no data stored i database a client-connection relies on.
I do understand the pooling in servlets and app-servers - but for my code it's a few administrators and a daily cronjob. Maybe the one who suggested DatSource to me didn't understood this.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop