SQL Server的数据源Microsoft JDBC驱动程序（AlwaysOn可用性组）

Question

当从使用Microsoft JDBC Driver 4.0的Java应用程序连接到具有AlwaysOn可用性组以设置高可用性的SQL Server 2014 ，我遇到与场景有关的问题。

通过此设置，我们将连接到可用性组侦听器（在db连接字符串中指定，而不是在任何特定实例中指定），以便该侦听器正常处理数据库故障转移等，并尝试连接到如果当前主要节点在AG集群中出现故障，则场景中的下一个可用实例。

我的问题是

1. 在j2ee应用程序服务器端配置的数据源（我们使用WebSphere）中，那些已经由数据源池化的连接会发生什么？

2. 当数据库发生故障时，尽管AG侦听器会尝试在db端重新连接到下一个可用的DB，但AG侦听器还会通过jdbc驱动程序向在应用服务器上创建的数据源发送事件或事件，并进行确保已经被数据源池化的那些连接将被丢弃并让其创建新连接，以使应用程序端的事务不会失败（尽管它们可能会持续一段时间，直到创建新连接并成功进行故障转移）或java应用程序仅在从数据源请求后才需要查找？

Answer 1

该SQL Server JDBC驱动程序的版本4很旧，对常开功能一无所知。

可以将任何数据源连接池配置为在将其分发给客户端之前检查来自该池的连接状态。 如果无法使用该连接，则池将创建一个新的连接。 所有供应商和版本都是如此。 我相信这是您可以做的最好的事情。

Answer 2

WebSphere Application Server能够处理错误的连接并将其从池中除去。 究竟何时发生，取决于某些可配置的选项以及Microsoft JDBC驱动程序充分利用javax.sql.ConnectionEventListener API将通知发送到应用程序服务器的能力。 在理想的情况下，JDBC驱动程序立即为所有连接发送connectionErrorOccurred事件，WebSphere Application Server通过从池中除去所有这些连接并通过将当前正在使用的任何连接标记为不良来响应，从而不会返回它，从而做出响应。一旦应用程序关闭了句柄，就将池添加到池中。 缺少此功能，WebSphere Application Server将在应用程序下次使用时发现第一个不良连接。 可以通过当时由JDBC驱动程序发送的connectionErrorOcurred事件来发现它，或者通过检查异常的SQLState /错误代码以了解不良连接的已知指示器来发现该事件。 然后，WebSphere Application Server将根据已配置的清除策略从池中清除不良连接。 有3种选择：

1. 整个池的清除策略-将所有连接从池中删除，并将正在使用的连接标记为不良，以便不对其进行池化。
2. 仅清除连接失败的清除策略-仅将实际发生错误的特定连接从池中删除或标记为不良而不返回到池中
3. 验证所有连接的清除策略-测试所有连接的有效性（Connection.isValid API），发现不良的连接将从池中删除或标记为不良，而不返回到池中。 被发现有效的连接保留在池中并继续使用。

根据您的描述，我不确定您使用的是传统的WebSphere Application Server还是Liberty。 如果是传统的，则在将连接从池中移出时，还可以使用其他选项进行预测试，但是请注意，将其打开可能会影响性能。 就是说，需要注意的一件事是，无论上述任何情况如何，您的应用程序都将始终需要能够处理由于不良连接而导致的错误可能性（即使清除了连接池，连接也可能变为不良状态）并通过请求新的连接并在新的事务中重试该操作进行响应。