|
Also Read these White Papers they are very good for Websphere Family. WS_BestPractices.PDF White paper IBM WebSphere Application Server Standard and Advanced Editions WebSphere Application Server Development Best Practices for Performance and Scalability by Harvey W. Gunther Document Revision Control: 1.1.0 Date: September 7, 2000 -----Original Message----- From: Fred Kulack [mailto:kulack@us.ibm.com] Sent: Thursday, June 28, 2001 10:32 AM To: JAVA400-L@midrange.com Subject: RE: JDBC Data Source I would add a couple of things to Rich's statements (they might have been in there, but I read it too quickly... 8-) The description of the DataSource given by Rich were predominantly from the view of the driver (that's good). Realize, that Websphere now duplicates the DataSource concept _again_ over the top of the particular JDBC driver provided DataSource objects OR over the top of plain old JDBC DriverManager.getConnection(). These are the 'wrappers' that Rich is talking about. I.e. in a Websphere environment, you don't really know or care that there exists a UDBDataSource. Instead, you create a Websphere DataSource (which might actually require you to tell Websphere which JDBC driver DataSource object to use, or more likely just which JDBC driver to use). The Websphere DataSource functions as an encapsulation of the JDBC specific 'stuff'. It delegates DataSource'ish operations to the appropriate parts of websphere. I.e. in a websphere environment, the JDBC Driver isn't necessarily responsible for connection pooling, but instead Websphere is because IT actually provides the implementation of the DataSource. (As Rich mentioned, in JDBC 3.0 more of this capability is moving to 'down' to the driver', but there's still no requirement that Websphere utilize the capabilities implemented by the driver instead of its own.). Here's the Key. Your application doesn't know or care whether its DataSource is JDBC driver provided or Websphere provided. It's just a DataSource. Deployment (putting the datasource into JNDI at the appropriate place) is the responsibility of Websphere based on your entries into the GUI. If you have a non websphere application that wants to use DataSources, there's some administrative stuff needed to put it into JNDI and its a small tool that you write on your own (I.e. Steal Rich's example and modify as you see fit. 8-) The technical facts that the DataSource can do cool pooling and other stuff from that post could confuse what I think is the real issue of the DataSource. The real issue is that the DataSource is provided by anyone. Its named anything, does just about anything, and can have a rich (no pun intended) set of functionality buried under the relatively simple connection factory sort of interface. It therefore allows your relatively simple java database code to run in extremely _varied_ environments. "The stuff we call "software" is not like anything that human society is used to thinking about. Software is something like a machine, and something like mathematics, and something like language, and something like thought, and art, and information... but software is not in fact any of those other things." Bruce Sterling - The Hacker Crackdown Fred A. Kulack - AS/400e Java and Java DB2 access, Jdbc, JTA, etc... IBM in Rochester, MN (Phone: 507.253.5982 T/L 553-5982) mailto:kulack@us.ibm.com Personal: mailto:kulack@bresnanlink.net AOL Instant Messenger: Home:FKulack Work:FKulackWrk +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.