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 <[EMAIL PROTECTED]> 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
