RE: JDBC Data Source

["Patrick L Archibald" <Patrick.Archibald@xxxxxxxxxxxxx>]

Very helpful. Thanx Fred. PLA

-----Original Message-----
From: owner-java400-l@midrange.com
[mailto:owner-java400-l@midrange.com]On Behalf Of Fred Kulack
Sent: Thursday, June 28, 2001 11: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
+---