struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Keays <>
Subject Re: Passing DataSource into Model-land at init
Date Fri, 31 May 2002 11:05:37 GMT
Adam Hardy wrote:

> Hi Jeff
> I'm at the same point as you in developing an app. I'm going to use the 
> Jakarta commons-dbpc & commons-pool.

Thanks for the tip.  I will probably try the commons-dbpc later on. 
That's the beauty of a standard interface like DataSource, the 
implementation can be switched later on without breaking things.

> I find your description of "passing DataSource into model at init time" 
> ambiguous - surely you don't have any model components hanging around in 
> sessions or application scope? You must mean when your Action perform() 
> invokes a model component by its constructor?

'Init time' in my parlance refers to when the webapp is first loaded, 
before the first request comes in.

I am referring to passing the DataSource object to a 'registry' (cf. the 
article you mentioned) in the model package, which other classes in the 
model package then use as a (recycling) 'factory' for pooled Connection 
objects for as long as the app is running. (without having to call back 
out to webapp-land, ever).

My current thinking is that objects from the model package are indeed 
destined to be cached in the session and application scopes, but only as 
generic Object references (Beans). i.e.:

- User submits login form.
- Login Action gets called, marshals username, password to login() 
function of business logic.
- Business logic consults database (with Connection from DataSource 
cached in 'registry')
- (If password is correct), login() returns new UserBean Object
- Login Action installs UserBean Object in session scope, then forwards 
to next page
- JSP components read whatever user-displayable junk they need from 
stored UserBean.

Is this not an acceptable way to do it?  IIUC You seemed to react with 
alarm to the notion ("surely you don't have any model components hanging 
around in sessions or application scope?").  Hence my explanation.

To me it seems cleaner to use static factory methods rather than allow 
actions to directly instantiate possibly-not-valid model components (cf 
UserBean). (Or perhaps I'm confusing the terminology and should be 
calling them state beans or something else?)  It is easy enough to make 
the constructors private.  Plus if the objects are largely static they 
could be cached and/or shared, improving performance.

This happens after 'init time', so it does not pertain to the question I 
was asking.

>  From general discussion on this list your assumption about the 'right 
> way' would be correct - pass all you need into the model components as 
> parameters.

By subclassing ActionServlet to properly initialize the back end, then 
using that ActionServlet rather than the 'stock' one?

> I did read about a "Register" design pattern on 
> , where objects (your configuration 
> singleton class in model-land?) are held in a hashtable indexed by 
> thread Id for thread safety, but the author then said he didn't like 
> this since "global data is inherently dangerous". Doing this would then 
> couple your model and your control layers together, which you didn't 
> want to do - they would both have to know where it's stored.

Thanks for the link.  I read the article and it seems to pass most of 
his requirements for implementing the 'registry' as a static singleton 
(i.e. small, finite number of objects to cache that are essentially 
immutable (the references anyway) after initialization.  I will make 
sure to use accessors so any necessary thread-safety singing and dancing 
can retrofitted later without annoying the callers.

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

View raw message