Thanks to everyone who's commented on this - I can't believe that I hadn't come across the JNDI solution, but it's working beautifully now. So onto the next, closely related issue...
I'm accessing my database, via JNDI, using a class called DatabaseManager. My aim is that this class abstracts the database backend, so I can just call addUser(myUser), and it will take care of the SQL stuff behind the scenes. At the moment, this DatabaseManager contains code similar to Soefara's below to get a connection for itself whenever it has to make a db request. My confusion is what to do with this class - Should I declare it as abstract? Does that ruin some of the pooling stuff? I would really like to be able to create a global instance of this class, instantiated when the server starts, since individual requests don't need their own DatabaseManager. But I'm using Struts, and I don't know how to do that! Arghh... Any thoughts/experiences? Ric Searle Web Application Developer -- Dialogue Communications Ltd http://www.dialogue.co.uk +44 (0) 114 221 0307 On Thursday, April 11, 2002, at 06:02 pm, Craig R. McClanahan wrote: > > > On Thu, 11 Apr 2002, Soefara Redzuan wrote: > >> Date: Thu, 11 Apr 2002 10:46:14 +0800 >> From: Soefara Redzuan <[EMAIL PROTECTED]> >> Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Subject: Re: Tomcat 4.x and Database Connection Pooling >> >>> Tomcat: As far as I'm concerned, JNDI support is a "now and forever >>> more" >>> feature of Tomcat 4 and later. It's the standard access mechanism >>> for J2EE >>> app servers as well. >> >> This is what I love to hear. With so many changes (servlets to JSP to >> Struts) over the last few years, future-proofing is so important. >> >>> Recommendation: If you can, you should use JNDI based access to data >>> sources. This is both portable across containers, and portable across >>> Struts versus non-Struts applications. >> >>> In addition, it can be used from >>> directly from within a JavaBean implementing your business logic, >>> without requiring a reference to ActionServlet or the servlet context >>> (or >>> the web layer at all). >> >> Really ? This is incredibly important news to me. I've been acquiring >> the >> JNDI resource within my servlet then passing it as a parameter to my >> Javabean which is a terrible mechanism because it makes my javabean >> dependent on the servlet :( >> >> So, are we saying that once we've set up a pooled database connection >> JNDI >> resource in server.xml and web.xml, any Javabean that is called by a >> serlvet >> or JSP can make use of this JNDI resource directly like this >> >> >> In the javabean. >> ---------------- >> import javax.naming.NamingException; >> import javax.naming.Context; >> import javax.naming.InitialContext; >> import javax.naming.NamingEnumeration; >> import javax.naming.directory.InitialDirContext; >> >> class mybean() { >> java.sql.Connection conn >> .... >> get getPooledDatabaseConnection() { >> Context ctx = new InitialContext(); >> Context envCtx = (Context) ctx.lookup("java:/comp/env/"); >> DataSource ds = (DataSource) envCtx.lookup("jdbc/dbpool"); >> conn = ds.getConnection(); >> } >> ... >> } >> >> If so, this is going to make development much easier. :-) >> > > Yep ... that is exactly the pattern you can use. Nice, isn't it? > >> Soefara. >> > > Craig > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
