This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hai All, I am having a doubt regarding Drivermanager and Datasource. In case of JDBC connection in which situation we use Drivermanager and in which situation we will use Datasource. Can anyone clearly tell me the difference between Drivermanager and Datasource.
That is a misleading article. While there's nothing outright incorrect in it, it explains little, and advocates practices that are thoroughly out of fashion (like hard-coding the driver). To note: - DataSource can use JNDI, but doesn't have to. DriverManager can't. - Both can support connections pools and distributed transactions, but only DataSource makes that support visible to the host app (via the PooledConnection and XAConnection interfaces).
I think DataSource should always be used to obtain a Connection. One problem with DriverManager is that DriverManager.getConnection can cause a deadlock. In a server platform, all DriverManager calls are class-synchronized including many frequent calls that all drivers make, and JDBC drivers do a lot of synchronization internally. One long-waiting call can stop all JDBC work in the whole JVM and cause deadlocks.
I'm accustomed to obtaining a DataSource from a container's JNDI tree, but people working without a container should be able to instantiate the DB's DataSource class and set the required attributes (like server name, database name, port number).
What's the minimum environment surrounding a DataSource? Can we use them in a straight POJO application? We use them in an EJB container and the vendor framework builds up dependencies that make it impossible to unit test much of the code outside the EJB container.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Mar 22, 2005
You don't need any kind of container or JNDI to use a DataSource. The drawback is that -w/o JNDI- you will have to write driver-specific code, because DataSource does not have another generic way to obtain connections besides JNDI. But for unit testing this might be a perfectly acceptable tradeoff. E.g., for the DB2 driver, check out this article to see how it's done.
Joined: Jan 29, 2003
Thanks! I may be able to use this in some testing scenarios where I thought I had to run in the whole darned framework just to get a datasource.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com