tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Morelock <subscripti...@phillipmorelock.com>
Subject Re: Connection Pooling Solution
Date Thu, 30 May 2002 21:19:35 GMT
On 5/30/02 2:05 PM, "Cindy Ballreich" <cindy@ballreich.net> wrote:
> Yes, much more so. Thanks! I was misunderstanding the whole relationship. I

Cool!

Yeah, if you look at the packages:
javax.servlet.http
and
javax.sql
and
java.sql

I think you'll start to see how powerful the concept of interfaces has been
in propelling Java adoption forward.

If you look at them by browsing the frames-based javadoc, you'll note that
most of the class names are in italics -- this means they're interfaces.
Any vendor can then step up to the plate and make a driver / implementation
for their product, and as long as it provides programmatic access via those
Sun-specified interfaces, Java application-level programmers like you and I
can just code our programs to work based on only the interfaces.

Whenever you want to swap out the underlying implementations (MySQL vs.
Oracle, Tomcat vs. WebLogic, even most of the time just the version upgrade
from Tomcat 3 to Tomcat 4, etc.) you likely don't have to change a lick of
code for your application, only a config file or perhaps one hardcoded place
in one source file.  This really is "write once, run anywhere" on a whole
other level.

cheers and have fun
fillup


On 5/30/02 2:05 PM, "Cindy Ballreich" <cindy@ballreich.net> wrote:

> fillup,
> 
> At 01:28 PM 5/30/02 -0700, Phillip Morelock wrote:
>> javax.sql.DataSource itself is not returning Connections.
>> 
>> DataSource is an interface -- what this means in practice is that some
>> random class (in this case, BasicDataSource) is implementing that interface.
>> You're actually asking that class for a Connection, and you "know" that you
>> can call any method on it that is defined in javax.sql.DataSource because it
>> implements that interface.  So while your code might hypothetically look
>> like (partially pseudo-code):
>> BasicDataSource bds = Somewhere.getDataSourceObject();
>> Connection conn = bds.getConnection() ;
>> 
>> it's far more flexible to do this:
>> DataSource ds = Somewhere.getDataSourceObject();
>> Connection conn = ds.getConnection();
>> 
>> If you get another database connection pool (say, from MS or Oracle or
>> something) and you want to change the actual class for the DataSource (say,
>> now it's "MSSQLServerDataSource" or whatever) -- as long as that next class
>> still implements the javax.sql.DataSource interface, you can still work with
>> it without changing any of your code, just the config file that tells Tomcat
>> which DataSource class to use.
>> 
>> So all you would do if you have to change databases or driver classes, is
>> change web.xml or server.xml or wherever you have the driver / data source
>> class configured, and all your code can remain using "DataSource" as the
>> type of the object, no changes from "BasicDataSource" to
>> "MSSQLServerDataSource" all over the place.
>> 
>> Is this clear?
>> 
> 
> Yes, much more so. Thanks! I was misunderstanding the whole relationship. I
> spent some time going over the source for BasicDataSource and I think I'm much
> clearer on the whole thing.
> 
> Cindy
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message