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
> http://martinfowler.com/isa/ , 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
