Hey,
I tried this approach and it is working
private static DataSource ds;
/**
* You must call <code>Database.init()</code> before using
* any of the methods in this class.
*/
public static void init() throws Exception {
Context ctx = new InitialContext();
ds = (DataSource)ctx.lookup("java:comp/env/jdbc/TestDB");
inited = true;
}
You can either call Database.init() in your controller servlet or use
lazy initialization. Using the latter, you will make all your methods
call Database.init().
I have not done any heavy load testing yet, but it works great across
multiple controller servlets.
(I wanted to test with JMeter, but JMeter requires Java 1.4, which is
not available on Mac os x.)
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 15 Oct 2002, Paul French wrote:
>
> > Date: Tue, 15 Oct 2002 12:30:19 +0100
> > From: Paul French <[EMAIL PROTECTED]>
> > Reply-To: Jakarta Commons Users List
> <[EMAIL PROTECTED]>
> > To: "'[EMAIL PROTECTED]'"
> <[EMAIL PROTECTED]>
> > Subject: dbcp question
> >
> > When a database connection pool is created using the usual lookup
> code
> >
> > Context initContext = new InitialContext();
> > Context envContext =
> (Context)initContext.lookup("java:/comp/env");
> > ds = (DataSource)envContext.lookup("jdbc/SID");
> >
> > Where should this be executed?
> >
> > Should it only be called once per webapp to obtain a pool of
> connections?
> >
>
> If you are taking the JNDI lookup approach, you will generally call
> the
> code described above, plus a little bit more, every time you need a
> Connection object to interact with the database, such as in a DAO
> object
> that wants to execute a query, or persist its current state:
>
> InitialContext initContext = new InitialContext();
> Context envContext = (Context) initContext.lookup("java:comp/env");
> DataSource ds = (DataSource) envContext.lookup("jdbc/SID");
> Connection conn = ds.getConnection();
> ... perform your database operations ...
> conn.close();
>
> When used in a connection pool environment, the close() method does
> not
> actually close the physical connection -- it simply returns the
> connection
> to the pool.
>
> You want to make the call every time, rather than caching and saving
> the
> data source once, for at least the following reasons:
>
> * If you call it only once, you have to pass a DataSource
> or Connection parameter in to every method that needs one.
> Using the recommended technique, any code that needs access
> to the database is responsible for getting its own connection.
>
> * In a high-availability environment, the server administrator
> might have replaced the connection pool on the fly (for example,
> if the database had to be restarted).
>
> There's some examples of this in the Tomcat docs:
>
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples-howto.html
>
>
> > If it is called repeatedly does tomcat simply return the same
> connection
> > pool instance?
> >
>
> Tomcat returns the same DataSource instance, but other servers might
> not.
>
> > Are the calls to getConnection() thread safe?
>
> Yes, but the Connection object you get back isn't -- it should be
> used
> only in the context of a single request processing thread. You also
> need
> to make absolutely sure that you return the connection to the pool,
> no
> matter what sort of exceptions happen. Using a "finally" block as
> shown
> in the docs above is a good technique to manage this.
>
> >
> > You can see my lack of understanding is coming from the fact that I
> want to
> > share the connection pool across multiple servlets. I also need to
> know if I
> > have to wrap the getConnection() call in a synchronized bloke to
> avoid
> > multiple threading issues.
>
> Nope -- you'll be fine on this issue.
>
> >
> > If you can provide some insight that would be much appreciated
> >
> > Paul
> >
> >
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
=====
Garrett Smith
http://dhtmlkitchen.com/
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
