beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chad Schoettger" <chad.schoett...@gmail.com>
Subject Re: Idea for JDBC system control
Date Wed, 13 Dec 2006 04:13:11 GMT
Hi Drew,

I haven't had a chance to look at your patch yet (hopefully I'll have
some time tomorrow) but I think the best solution may be to leave the
aquisition/release of the connection in the onAcquire/onRelease
methods.

When using a JDBC control from a page flow these events provide a
reasonably nice way of managing the connections. The connection is
basically scoped for the page flow method the control is being invoked
from:

MyPageFlow.java

   @Control private JDBCControl _myJdbcControl;

   myAction() {
       _myJdbcControl.getRow()   /* causes onAcquire() to be invoked */
       _myJdbcControl.getAnotherRow() /* does NOT cause onAquire() to
be invoked */
       ......
       ......
       return ....   /* causes onRelease() to be invoked() */
   }

I really like the idea Eddie mentioned about having a set method for
the connection -- if the user sets the connection, the jdbc control
closes an open connection if it has one and uses the one provided by
the user and basically noops in the onAcquire/onRelease methods.  If
the user sets the connection to null, the onAcquire/onRelease default
behavior resumes.

I do apologize if you were already aware of when onAcquire/onRelease
were invoked, it seems to be an area which causes a fair amount of
confusion.

   - Chad




On 12/11/06, Drew Varner <drew.varner@redops.org> wrote:
> Ok, I now see why the connection cannot be closed immediately after
> invoke: ResultSet results and possibly connected RowSets.
>
> Would it be possible to flag SQL methods to indicate that they don't
> depend on an open connection? This option would not break existing
> implementations.
>
> Another option would be to check the return type of the method. If
> the return type is ResultSet or RowSet, we don't close it. I don't
> like this solution as much. If a custom mapper does something weird
> like wrapping a RowSet, we'll never know. This solution seems like
> more of a hack.
>
> - Drew
>
>
> On Dec 11, 2006, at 10:57 PM, Drew Varner wrote:
>
> > I attached the patch to BEEHIVE-1019 (http://issues.apache.org/jira/
> > browse/BEEHIVE-1019).
> >
> > The patch I attached moves getConnection() from onAcquire() to
> > invoke().
> >
> > In the current version (grab connection when control is acquired)
> > or the new version (if my patch is accepted) of the JDBC Control,
> > the connection is pulled and held for quite a while. Imagine an app
> > has 10 database controls that point to the same database. If they
> > are used in the same Pageflow, it eats up 10 connections to the
> > database. That's a lot of overhead for one Pageflow to inflict on a
> > DataSource.
> >
> > Is there a reason not to move getConnection() at the beginning of
> > invoke() and then close it out at the end of invoke()? This would
> > be nice for JDBC controls with ConnectionDataSource annotations. If
> > there is some reason to hold on the connection like the current
> > implementation, could we set up an annotation to allow this
> > connection-conserving behavior?
> >
> > - Drew
> >
> > On Dec 1, 2006, at 10:07 AM, Eddie O'Neil wrote:
> >
> >> Drew--
> >>
> >>  Definitely -- this would be a great feature that would help with the
> >> situations you described.   Today, it's not possible to manage the
> >> Connection directly which makes it impossible to share it between two
> >> JdbcControl instances.  It might be possible to just add a method
> >> like:
> >>
> >>  public void setConnection(Connection conn)
> >>
> >> that if called will short circuit the Connection creation code in the
> >> JdbcControl.
> >>
> >>  This might be easy to add to the Control -- feel free to give it
> >> a shot.  :)
> >>
> >> Eddie
> >>
> >>
> >> On 11/30/06, Drew Varner <drew.varner@redops.org> wrote:
> >>> I was playing around with an idea for the JDBC system control. The
> >>> ability to pass it a Connection object other than one declared in
> >>> it's annotations.
> >>>
> >>> Here are a couple of use cases:
> >>>
> >>> 1) Integration with other persistence mechanisms. Let's say I have a
> >>> DAO that I can pass a Connection to. I can place the DAO and and
> >>> JDBC
> >>> Control operations in the same transaction.
> >>>
> >>> Connection conn = JDBCUtils.getConnection();
> >>> conn.setAutoCommit(false);
> >>> myJdbcControl.setExternalConnection(conn);
> >>> myJdbcControl.depositMoney(1000)
> >>> AccountAuditDAO.logDepositTransaction(1000,conn);
> >>> conn.commit();
> >>> conn.close();
> >>>
> >>> 2) Use it to put multiple JDBC Controls in the same db transaction
> >>> (same as above, replace the DAO with another JDBC control)
> >>>
> >>> 3) Make unit testing easier. You can pass a connection to a test
> >>> database into the control during testing and don't have to mess with
> >>> the JNDI setup for out-of-container testing.
> >>>
> >>> 4) Support for non-standard Connection sources. If you are using a
> >>> JDBC Control in a Struts app, you can grab the DataSource via the
> >>> Struts DataSource mechanism.
> >>>
> >>> Setting an external connection would be manipulated by methods, not
> >>> annotations.
> >>>
> >>> public void setExternalConnection(Connection conn);
> >>> public Connection getExternalConnection();
> >>>
> >>> The control implementation would never close the external
> >>> connection.
> >>>
> >>> Would it be worth adding?
> >>>
> >>> - Drew
> >>>
> >>>
> >>>
> >
>
>

Mime
View raw message