That options could work and I thank you for the positive feedback. What I have done is created a wrapper around my JdbcControls that de-couples it from the custom control that consumes it's services. That way, I can create the JdbcControl whenever I want and destroy when I am finished with it.
Chad Schoettger-2 wrote: > > Depending on the specifics of you implementation, you may be able to > use the @ConnectionOptions.useExternalConnection annotation (defined > in the JdbcControl interface) to reduce the number of JDBCConnections > used. > > If the useExternalConnection annotation has a value of true, the JDBC > control will not acquire its own connection, instead it will use the > Connection supplied by the JdbcControl.setConnection() API. > > - Hope this helps, > Chad > > > > On Mon, Jun 23, 2008 at 3:17 PM, Dan Anderson <[EMAIL PROTECTED]> > wrote: >> >> Hi, >> >> I have thus far built 20+ controls that extend JDBCControl, These >> JDBCContorls are used by dao objects. These dao objects are in turn >> custom >> beehive controls. The problem that I am running into is that the >> JDBCControls are not being cleaned up until the parent custom control is >> destroyed. I have gone so far as to null the control instance to force >> the >> onRelease() method to be fired. >> >> I need a way to force the connection to be released on demand. One of my >> more advanced JUnit tests is exhausting the connection pool and is >> failing. >> >> Any help would be greatly appreciated. >> -- >> View this message in context: >> http://www.nabble.com/Releasing-JDBCControl-connections-early-tp18078694p18078694.html >> Sent from the Beehive - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Releasing-JDBCControl-connections-early-tp18078694p18162210.html Sent from the Beehive - User mailing list archive at Nabble.com.
