Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 1 Jan 2015 20:29:13 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12728195.1405687354000.124290.1420144153517@Atlassian.JIRA>
In-Reply-To: <JIRA.12728195.1405687354000@Atlassian.JIRA>
References: <JIRA.12728195.1405687354000@Atlassian.JIRA>
 <JIRA.12728195.1405687354544@arcas>
Subject: [jira] [Commented] (DBCP-423) PoolingDataSource should implement
 Closeable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262652#comment-14262652 ] 

Christian Schneider commented on DBCP-423:
------------------------------------------

For me having a close in PoolingDataSource would not help. I close the DataSource in pax-jdbc-config. There only DataSource is known and the module should have no dependency on dbcp. This is why I used Closeable as it is present in the jdk. So basically what I need is that the PoolingDataSource impl implements a standard java interface with a close method.

Honestly I think that not implementing something like Closeable in many Java APIs is the real smell .. together with Closeable.close throwing a checked exception which totally sucks from a client perspective. Still Closeable is the only present interface to mark that something can be closed. Btw. If you look at newer Java APIs like jms 2.0 you see that they extend AutoClosable. So I think the spec designers understood that they left out an important part by not having a universal closing facility and corrected this.

So of course extending Autoclosable would be the even better thing but it is Java 7 only so I do not know if it is ok for dbcp.


> PoolingDataSource should implement Closeable
> --------------------------------------------
>
>                 Key: DBCP-423
>                 URL: https://issues.apache.org/jira/browse/DBCP-423
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Christian Schneider
>             Fix For: 2.1
>
>
> Currently PoolingDataSource only implements DataSource. 
> I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in one bundle that can create a pooling DataSource.
> Then in another bundle I create DataSources based on config in ConfigurationAdmin. So when the config appears I create the DataSource, when the config goes away I have to destroy it.
> It is important to correctly dispose the DataSource as the pool has to be closed. As I can not depend on dbcp in the bundle that destroys the DataSource I currently have no simple way to destroy the DataSource.
> This is where I create the DataSource:
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
> I was able to solve it by a kind of hack. I extended the PoolingDataSource with a class that supports Closeable. So from the other bundle I could check if the object implements Closeable and call close.
> It would be a lot easier if PoolingDataSource would implement Closeable like I did. The same is true for GenericObjectPool and the other pools. If they would implement Closeable then handling them would be a lot easier.
> They already support a close method so it would be a small change.
> ----
> public class CloseablePoolingDataSource<C extends Connection> extends PoolingDataSource<C> implements Closeable {
>     public CloseablePoolingDataSource(ObjectPool<C> pool) {
>         super(pool);
>     }
>     @Override
>     public void close() throws IOException {
>         getPool().close();
>     }
> }


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)