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 <[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
>>>
>>>
>>>
>
