struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: accessing DataSource, webapp design question
Date Wed, 22 Jan 2003 20:14:02 GMT

On Wed, 22 Jan 2003, Charlie Toohey wrote:

> Date: Wed, 22 Jan 2003 10:31:23 -0800
> From: Charlie Toohey <>
> Reply-To: Struts Users Mailing List <>
> To:
> Subject: accessing DataSource, webapp design question
> This is more of a design question. I am using Struts and Tomcat, and have set
> up a JNDI ref-resource to acquire a DataSource for my database, which works
> fine.  All of my value objects use the same database.
> The question is how to give each value object access to this DataSource.
> One option would be to lookup the JNDI contexts once, at application init,
> and store the DataSource as an application scope attribute. Then whenever a
> value object needs to do database work, they access this DataSource and do a
> getConnection() / conn.close().
> Another option would be to have each value object do the JNDI lookups (say,
> in their constructors) and store the DataSource reference in a private field
> --- then anytime they need to do database work, they use the private field
> DataSource and do a getConnection() / conn.close()
> Is there any difference/advantage/disadvantage in having all value objects
> using the same DataSource reference, stored at application scope, vs. all
> value objects having their own reference to the DataSource ?
> Or another approach which is superior to these options ?

A third pattern is actually the recommended one -- do the lookup in your
value object every time.  It won't matter on Tomcat (which doesn't support
these features), but it allows high-availabity servers to support
transparent reconfiguration of existing connection pools, or even
switching to a backup database, without making you shut down your

Saving a reference to the connection pool you were given earlier makes all
of that kind of support difficult to impossible.

> Thanks,
> Charlie


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message