I've been grappling with this myself and I came across a couple other issues which may
be worth consideration.
I thought that it was import for my business methods to be re-entrant and support
transactions appropriately. This seems to be one of EJB's successes. A practical
scenario is: the controller calls method A which calls method B; the controller also
calls B directly. Each method may begin a transaction if it's a new request from the
application, but should only commit the transaction and return the connection back to
the connection pool once the control is passed back to the application.
Passing the connection in at the application layer does seem to address the problem
but doesn't separate concerns particularly well.
I considered two other options:
1) a proxy which maintains a reference to the connection pool and handles getting and
releasing the connection from the connection pool; or
2) The solution I've settled on for the moment is having the business methods have
access to a connection pool and manage getting and releasing the connection by using a
stack based reference counting scheme. The beginning of each transactional method
starts with beginTransaction() and ends with finally {endTransaction();}, from within
the transaction getConnection() always returns the same connection if the requesting
thread is the same.
Both of these methods insure that each individual controller-request has access to the
same connection for all database requests yet doesn't require the controller to
specifically pass requests.
The more I work on this kind of thing, the more I appreciate EJB... something that I
thought I'd never say.
----- Original Message -----
From: "Craig Tataryn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 06, 2002 1:16 PM
Subject: Re: Alternative Datsource Hot-potatoing...
> Thanks Craig. I'll take a look into option 3.
>
> Could you see a problem with me creating a class called "DataAdaptor" with a
> static method called "getConnection()" which is initialized apon application
> startup with the DataSource setup by Struts? Then using this static method
> in my data objects to grab a connection?
>
> Craig.
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >Subject: Re: Alternative Datsource Hot-potatoing...
> >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> >
> >
> >
> >On Fri, 6 Sep 2002, Craig Tataryn wrote:
> >
> > > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > > From: Craig Tataryn <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Alternative Datsource Hot-potatoing...
> > >
> > > I was wondering if someone could give me a heads up on some alternative
> > > means for which to give my data access layer access to my datasource.
> > >
> > > I don't really like the idea of my controller grabbing the Datasource,
> > > passing it off to my business layer, who in turn passes it along to my
> >data
> > > layer. I guess I'm sort of a purest, but I don't think the Business
> >layer
> > > should know anything about the database, and that means it shouldn't
> >even
> > > have methods that take connections or datasourses as parameters.
> > >
> > > I think the only thing I like about the Controller passing along a
> > > connection to my business/data layer is the fact that I can first open a
> > > transaction before passing the connection along, and then I can commit
> >the
> > > transaction when everything is done. Thus my transactions are at the
> > > controller level, and can be managed there.
> > >
> > > Back in my old VB/COM days, we had a sort of DB Utilities class which
> >could
> > > be accessed from the datalayer. You would ask it to give you a
> >connection,
> > > and it would get it for you. Should I make my own class for datasource
> > > access which is intitalized upon application start with the Datasource
> > > object found by struts? Then the rest of my datalayer can simply use
> >it?
> > >
> >
> >Three basic options exist:
> >
> >* Hand a DataSource (I normally prefer to send a Connection instead, but
> > either works) to your business logic method as a parameter to each call
> > that needs it. Advantage: no binding to anything. Disadvantage: can
> > be a pain to hand it around.
> >
> >* Static methods ... Most DB connection pool implementations offer a way
> > to retrieve a DataSource or Connection via a static method. Advantage:
> > no handing around extra method parameters. Disadvantage: ties you to
> > that connection pool's APIs.
> >
> >* JNDI resources -- All J2EE app servers (and some servlet containers like
> > Tomcat 4) offer support for JNDI resources that are accessible to your
> > business logic directly like this:
> >
> > import javax.naming.Context;
> > import javax.naming.InitialContext;
> >
> > InitialContext ic = new InitialContext();
> > Context ctx = (Context) ic.lookup("java:comp/env");
> > DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");
> >
> > where "jdbc/EmployeeDb" is a resource reference you have declared in
> > your web.xml file. Advantage: No parameter passing, no connection
> > pool API lock-in. Advantage: configuration of the data source is
> > external to your webapp (it's done with the server configuration
> > capabilities). Disadvantage: container must support this.
> >
> >For info on how to use the third option in Tomcat, see:
> >
> >
> >http://jakarata.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
> >
> >(NOTE -- if you're going to use Tomcat, definitely go for 4.1; 4.0's
> >support has problems for many users).
> >
> > > Thanks,
> > >
> > > Craig.
> > >
> > > Craig W. Tataryn
> > > Programmer/Analyst
> > > Compuware
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
>
>
> Craig W. Tataryn
> Programmer/Analyst
> Compuware
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
