MySQL :: MySQL NDB Cluster API 开发人员指南 :: 4.2.2.1 执行 ClusterJ 应用程序和会话

MySQL NDB Cluster API 开发人员指南 / ... / 执行 ClusterJ 应用程序和会话

4.2.2.1 执行 ClusterJ 应用程序和会话

在本节中，我们将讨论如何启动 ClusterJ 应用程序以及 ClusterJ 应用程序环境。

执行 ClusterJ 应用程序。 所有 ClusterJ jar 文件通常位于 MySQL 安装目录中的 share/mysql/java/ 中。执行 ClusterJ 应用程序时，必须设置类路径以指向这些文件。此外，必须设置 java.library.path 变量以指向包含 Cluster ndbclient 库的目录，该目录通常位于 lib/mysql 中（也在 MySQL 安装目录中）。因此，您可以使用类似于此处所示的方式执行 ClusterJ 程序 MyClusterJApp

$> java -classpath /usr/local/mysql/share/mysql/java/clusterj.jar \
              -Djava.library.path=/usr/local/mysql/lib MyClusterJApp

注意

ClusterJ jar 文件和 libndbclient 的确切位置取决于 NDB Cluster 软件的安装方式。有关更多信息，请参阅安装布局。

ClusterJ 鼓励您在编译时和运行时使用不同的 jar 文件。这是为了防止应用程序意外访问实现工件。ClusterJ 旨在独立于 NDB Cluster 软件版本，而 ndbclient 层是特定于版本的。这使得维护稳定的 API 成为可能，因此使用给定 NDB Cluster 版本针对其编写的应用程序在将集群升级到新版本后继续运行。

获取 SessionFactory 和获取会话。 SessionFactory 是使用给定 NDB Cluster 的所有 ClusterJ 会话的来源。通常，每个 Java 虚拟机每个 NDB Cluster 只有一个 SessionFactory。

可以通过设置一个或多个属性来配置 SessionFactory。首选方法是将这些属性放在属性文件中，如下所示

com.mysql.clusterj.connectstring=localhost:1186
com.mysql.clusterj.database=mydb

属性文件的名称是任意的；但是，按照惯例，此类文件使用 .properties 扩展名命名。对于 ClusterJ 应用程序，习惯上将文件命名为 clusterj.properties。

编辑并保存文件后，可以将其内容加载到 Properties 的实例中，如下所示

File propsFile = new File("clusterj.properties");
InputStream inStream = new FileInputStream(propsFile);
Properties props = new Properties();
props.load(inStream);

也可以不使用属性文件直接设置这些属性

Properties props = new Properties();

props.put("com.mysql.clusterj.connectstring", "localhost:1186");
props.put("com.mysql.clusterj.database", "mydb");

设置并加载属性后（使用上面显示的任一技术），您可以获取 SessionFactory，然后从中获取 Session 实例。为此，您可以使用 SessionFactory 的 getSession() 方法，如下所示

SessionFactory factory = ClusterJHelper.getSessionFactory(props);

Session session = factory.getSession();

通常，设置和加载 com.mysql.clusterj.connectstring 和 com.mysql.clusterj.database 属性就足够了（这些属性以及 com.mysql.clusterj.max.transactions 在启动 SessionFactory 后无法更改）。有关可用 SessionFactory 属性的完整列表以及常用值，请参阅 com.mysql.clusterj.Constants。

注意

不得在线程之间共享 Session 实例。应用程序中的每个线程都应使用其自己的 Session 实例。

对于 com.mysql.clusterj.connectstring，我们使用默认的 NDB Cluster 连接字符串 localhost:1186（有关更多信息，请参阅 NDB Cluster 连接字符串）。对于 com.mysql.clusterj.database 的值，我们在本例中使用 mydb，但此值可以是包含 NDB 表的任何数据库的名称。有关可以以此方式设置的所有 SessionFactory 属性的列表，请参阅 com.mysql.clusterj.Constants。

错误处理和重新连接。 使用 ClusterJ 时发生的错误应由应用程序使用通用的错误处理程序来处理。处理程序需要能够检测和区分三种类型的错误，并相应地处理它们

正常错误：这些是应用程序级别的错误（例如，处理重复键、外键约束或超时的错误）。它们应该以特定于应用程序的方式处理，如果解决，应用程序可以继续执行事务。
意外错误：这些是无法通过应用程序条件解释的与集群一起工作的故障，但并非致命错误。应用程序应关闭 ClusterJ 会话并重新打开一个新会话。
连接错误：这些是类似于错误 4009 和 4010 的错误，它们指示网络中断。根据是否已启用自动重新连接功能（适用于 NDB Cluster 7.5.7 及更高版本），有两种可能的情况
- 已启用自动重新连接： 当连接属性 com.mysql.clusterj.connection.reconnect.timeout 已设置为正数时，该功能启用，该正数指定以秒为单位的重新连接超时。
  
  当 ClusterJ 检测到与 NDB Cluster 断开连接时，它会将 SessionFactory 的 State 从 OPEN 更改为 RECONNECTING；然后，SessionFactory 等待应用程序关闭所有会话，然后尝试通过关闭连接池中的所有连接并使用原始池属性重新创建池来将应用程序重新连接到 NDB Cluster。重新建立所有连接后，SessionFactory 的 State 将再次变为 OPEN，应用程序现在可以获取会话。
  
  SessionFactory.getState() 方法返回 SessionFactory 的 State，它是 OPEN、RECONNECTING 或 CLOSED 之一。当 State 不是 OPEN 时尝试获取会话会导致 ClusterJUserException，并显示消息会话工厂未打开。
  
  如果应用程序在使用 com.mysql.clusterj.connection.reconnect.timeout 指定的超时时间结束时未关闭所有会话，则 SessionFactory 将强制关闭任何打开的会话（这可能会导致资源丢失），然后尝试重新连接。
- 未启用自动重新连接： 这是指未设置连接属性 com.mysql.clusterj.connection.reconnect.timeout，或已将其设置为零（对于不支持自动重新连接功能的旧版 NDB Cluster 版本也是如此）。
  
  ClusterJ 在连接断开后不会尝试重新连接到 NDB 集群。应用程序应关闭所有会话，然后重新启动 SessionFactory。重新启动 SessionFactory 可以是自动应用程序功能或手动干预。无论哪种情况，代码都应等到所有会话都已关闭（即，SessionFactory 接口中的公共方法 getConnectionPoolSessionCounts() 为所有池连接返回零）。然后可以关闭并重新打开 SessionFactory，并且应用程序可以再次获取会话。
除了启用该功能并等待 ClusterJ 检测到断开连接并尝试重新连接之外，您还可以让应用程序本身在检测到连接错误时通过调用 SessionFactory.reconnect(int timeout) 方法来启动重新连接过程：这将触发上述重新连接过程，但使用 reconnect() 方法的 timeout 参数作为关闭所有打开会话的时间限制。

日志记录。 ClusterJ 使用 Java 日志记录。以下是 ClusterJ 日志记录的一些默认设置，这些设置在 logging.properties 文件中指定，并且可以在其中进行修改

所有类的日志记录级别都设置为 INFO。
使用 java.util.logging.FileHandler 作为处理程序。
java.util.logging.FileHandler 的默认级别设置为 FINEST
使用 java.util.logging.SimpleFormatter 作为处理程序的格式化程序。
日志文件放在当前工作目录下的 target 目录中，文件名通常采用 logNum 的模式，其中 Num 是用于解决文件名冲突的唯一编号（有关详细信息，请参阅 java.util.logging.FileHandler 的 Java 文档）。

logging.properties 文件默认位于当前工作目录中，但可以通过在启动 Java 时指定系统属性 java.util.logging.config.file 来更改位置。