beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Varner <drew.var...@redops.org>
Subject Re: Idea for JDBC system control
Date Tue, 12 Dec 2006 03:57:21 GMT
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