I hear where you are coming from. In the VB/COM app I was involved with,
all our DB transactions were handled by MTS. The stack thing seems
interesting, but how do you allocate one stack per request?
You wouldn't happen to be able to share any of the code you speak about in
your 2nd method can you?
Thanks,
Craig.
>From: "Philip S. Constantinou" <[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 14:27:21 -0700
>
>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]>
> >
> >
Craig W. Tataryn
Programmer/Analyst
Compuware
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
