commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <...@hazlewood.com>
Subject Re: JNDI, Tomcat, Distributed Apps, et al.
Date Sat, 15 Jun 2002 22:33:36 GMT

> conceptually, you should be able to bind an object factory into one of
> these, but I've never tried it.  The other approach would be to write your
> own implementation of javax.naming.Context and set the appropriate system
> properties to use your version -- details in the JNDI spec and tutorials.

Nah, I was just seeing if I could just use the same database lookup code in 
a container deployed system as I could with a standalone app.  Its not hard 
to write the extra code and have an abstract class defining common 
functionality across both implementations. 


> J2EE describes the overall application development and installation
> process in terms of roles, and (in particular) defines a "deployer" role
> where the responsibility is to resolve all of the "resource references" in
> a deployment descriptor to match up to the actual resources to be used.

Very handy, thanks for the info. 


> connection pool actually does -- it pools a set of java.sql.Connection
> objects.  In the usual case, there will be some sort of TCP socket nested
> inside that connection for use in communicating to the real database -- so
> you can't share Connection instances across different JVMs anyway.

Doh!  Obviously....I completely forgot about that. 


> is "yes".  I'm not sure what different it makes to an application, though;
> the J2EE platform standard is to access a java.sql.DataSource instance
> from your JNDI naming context, which DBCP already supports.  (See the J2EE
> platform specification for dteails.)
 

With new JDBC specs you can do stuff like: 

DataSource ds = context.lookup("jdbc/whatever"); 

if (ds instanceof ConnectionPoolDataSource)
{
   /* return a connection from the pool: */
   PooledConnection pc = ds.getPooledConnection();
   Connection conn = pc.getConnection();
   return conn;
}
else /* return a non-pooled connection */
   return ds.getConnection();
 

I think the above was created to solve problems that the DBCP developers had 
already solved via their own methods.  What this achieves, I'm not exactly 
sure, but I'm sure the Java folks created it for a reason... 


> Craig
 

Thanks so much for your info and timely reply.  You are a great help! 

Les

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


Mime
View raw message