Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
From: mtaylor <git@git.apache.org>
To: dev@activemq.apache.org
Reply-To: dev@activemq.apache.org
References: <git-pr-1576-activemq-artemis@git.apache.org>
In-Reply-To: <git-pr-1576-activemq-artemis@git.apache.org>
Subject: [GitHub] activemq-artemis issue #1576: ARTEMIS-1447 JDBC NodeManager to support JDBC ...
Content-Type: text/plain
Message-Id: <20171017103429.9CB75DFAB2@git1-us-west.apache.org>
Date: Tue, 17 Oct 2017 10:34:29 +0000 (UTC)
archived-at: Tue, 17 Oct 2017 10:34:32 -0000

Github user mtaylor commented on the issue:

    https://github.com/apache/activemq-artemis/pull/1576
  
    @franz1981 Yes, I meant using a generic connection pool implementations as they reset the connection on release for isolation across components sharing the same pool.  I understand that reconnect is not part of the spec, but it's such a fundamental piece of functionality I'd be surprised if it wasn't already handled in drivers for all our supported DBs.  
    
    I'm not against the idea of using a connection pool (I responded to the comment and missed the fact that you'd implemented your own pool).  This is all good, but is it required for this JIRA?  It's more complexity that may not be required.  For what you're trying to achieve a generic pool would probably suffice.  How about doing something simple for stage 1 to get the HA functionality working.  We can optimise when required.  I would suggest, getting the basic stuff in commit 1, and optimisations in subsequent commits (could be the same PR) but makes it a lot easier to review and track down issues later.


---