本文旨在解决java桌面应用中多用户同时访问单一数据库的挑战，特别是针对apache derby嵌入式数据库的场景。我们将深入探讨嵌入式与客户端/服务器模式的区别，指出常见问题如“sealing violation”的根源，并提供实现多连接的正确方法，包括部署数据库服务器、选择合适的事务隔离级别以及利用现代化数据访问框架来简化并发控制。
理解数据库连接模式：嵌入式与客户端/服务器
在构建多用户应用时，首先需要理解数据库的两种基本连接模式：嵌入式（Embedded）和客户端/服务器（Client/Server）。这对于正确处理并发访问至关重要。
嵌入式数据库的局限性
Apache Derby、H2、HSQLDB等数据库都支持嵌入式模式。在这种模式下，数据库引擎作为应用程序的一部分，在同一个Java虚拟机（JVM）中运行，并直接访问数据库文件。其主要特点和局限性包括：
单JVM独占性： 通常，一个嵌入式数据库的数据文件只能被一个JVM实例独占。当第二个JVM尝试连接到同一个数据库文件时，会因为文件锁定或其他资源冲突而失败。这正是原始问题中出现 java.lang.SecurityException: sealing violation 错误的原因之一，尽管 sealing violation 更直接指向类路径中存在重复或冲突的Derby JAR包。资源管理： 数据库的启动、关闭和资源管理都由应用程序本身负责。不适合多用户并发： 嵌入式模式并非为多个独立的应用程序（或多个JVM实例）同时访问而设计。
客户端/服务器模式的必要性
对于多用户或多应用程序并发访问的需求，客户端/服务器模式是标准且推荐的解决方案。在这种模式下：
独立的数据库服务器： 数据库引擎作为一个独立的进程（服务器）运行，监听特定的网络端口。多客户端连接： 多个客户端应用程序通过网络连接到这个数据库服务器，发送SQL请求并接收结果。数据库服务器负责管理数据文件、并发控制、事务处理和锁定机制。高并发与稳定性： 这种模式能够有效处理来自不同客户端的并发请求，提供更好的稳定性和数据一致性。
解决方案一：部署独立的数据库服务器
解决多用户并发访问问题的最直接且推荐的方法是，将数据库部署为独立的服务器进程。
立即学习“Java免费学习笔记（深入）”；
配置Derby为网络服务器模式
Apache Derby 可以轻松配置为网络服务器模式。一旦以服务器模式运行，多个Java应用程序就可以通过JDBC网络驱动程序连接到它。
启动Derby网络服务器的步骤：
确保Derby JAR包可用： derby.jar 和 derbytools.jar。命令行启动：
java -jar %DERBY_HOME%/lib/derbyrun.jar server start
或者指定监听地址和端口：
java -Dderby.drda.host=0.0.0.0 -Dderby.drda.port=1527 -jar %DERBY_HOME%/lib/derbyrun.jar server start
这将启动一个Derby服务器，默认监听 localhost:1527。
创建或指定数据库：
# 在服务器启动后，客户端连接时指定数据库路径# 或者通过系统属性指定默认数据库目录# java -Dderby.system.home=/path/to/your/databases -jar %DERBY_HOME%/lib/derbyrun.jar server start
Java客户端连接代码示例：
当Derby服务器启动后，客户端应用程序需要使用不同的JDBC URL来连接。
import java.sql.*;import javax.swing.JOptionPane;public class DerbyClientConnect { public Connection connectToDerbyServer() { Connection con = null; try { // 加载Derby网络客户端驱动 Class.forName("org.apache.derby.jdbc.ClientDriver"); // 连接到运行在localhost:1527的Derby服务器上的VERe数据库 // create=true 参数会在数据库不存在时创建它（仅第一次连接时有效） String host = "jdbc:derby://localhost:1527/C:DATABSE_SUBVERe;create=true"; String uName = "josh"; String uPass = "1234"; con = DriverManager.getConnection(host, uName, uPass); System.out.println("成功连接到Derby网络服务器。"); return con; } catch (ClassNotFoundException e) { JOptionPane.showMessageDialog(null, "Derby客户端驱动未找到: " + e.getMessage()); } catch (SQLException err) { JOptionPane.showMessageDialog(null, "数据库连接错误: " + err.getMessage()); } return null; } public static void main(String[] args) { DerbyClientConnect client = new DerbyClientConnect(); Connection connection1 = client.connectToDerbyServer(); Connection connection2 = client.connectToDerbyServer(); // 模拟第二个客户端连接 if (connection1 != null && connection2 != null) { System.out.println("两个连接都已建立，可以并发操作。"); try { connection1.close(); connection2.close(); } catch (SQLException e) { e.printStackTrace(); } } }}
其他推荐的数据库
除了Derby，还有许多更成熟、功能更强大的关系型数据库适合多用户环境，例如：
PostgreSQL： 功能强大、社区活跃、稳定性高，是企业级应用的优秀选择。MySQL： 广泛使用、易于部署，适合中小型应用。H2 Database (Server Mode)： H2不仅支持嵌入式，也支持服务器模式，且性能优异，是Java应用中一个非常灵活的选择。
解决方案二：在单JVM中模拟多用户访问（特定场景）
如果由于某种限制，必须在不部署独立服务器的情况下实现“多用户”访问，且这些“用户”实际上是同一台机器上的多个Java应用程序，那么需要一个更复杂的策略：
H2或HSQLDB的TCP/IP服务器模式： 这些数据库可以在一个JVM中启动一个轻量级的TCP/IP服务器，然后其他JVM通过这个本地服务器连接。这本质上是将一个JVM变成了“数据库服务器”。主应用程序管理数据库： 只有一个主应用程序（JVM）以嵌入式模式直接访问数据库文件。其他应用程序通过TCP/IP连接到这个主应用程序提供的数据库服务。复杂性： 这种方案增加了应用程序的复杂性，需要管理主应用程序的生命周期，以及处理连接和断开逻辑。通常不推荐，除非有非常特殊的限制。
高级并发控制与事务隔离
一旦数据库运行在服务器模式下，并支持多连接，接下来就需要关注并发控制和事务隔离级别，以确保数据的一致性和完整性。
事务隔离级别回顾
JDBC提供了多种事务隔离级别，用于定义事务之间如何相互影响：
AI Humanize
使用AI改写工具，生成不可被AI检测的文本内容
154 查看详情 TRANSACTION_READ_UNCOMMITTED：最低级别，可能出现脏读、不可重复读和幻读。TRANSACTION_READ_COMMITTED：防止脏读，但可能出现不可重复读和幻读。原始问题中尝试设置此级别，但它并不能完全解决所有并发问题。TRANSACTION_REPEATABLE_READ：防止脏读和不可重复读，但可能出现幻读。TRANSACTION_SERIALIZABLE：最高级别，防止所有并发问题（脏读、不可重复读、幻读），保证事务的串行执行效果。
推荐 SERIALIZABLE 隔离级别及其挑战
对于涉及读取后写入（Read-Modify-Write）的复杂业务逻辑（如银行转账），TRANSACTION_READ_COMMITTED 或更低级别是不安全的。例如，在两个并发事务中，如果都读取了账户余额，然后各自进行扣款，最终可能会导致余额错误。
SERIALIZABLE 隔离级别是确保数据一致性的最强保证。它强制事务表现得如同它们是串行执行的一样，从而避免了各种并发异常。
然而，SERIALIZABLE 也有其挑战：
性能开销： 数据库需要进行更多的锁定和资源管理，可能导致性能下降。死锁与重试： 在高并发场景下，SERIALIZABLE 事务更容易遇到死锁或“序列化失败”异常（SQLException），此时数据库会强制回滚其中一个事务。应用程序需要捕获这些特定异常，并实现事务重试机制。
示例：不安全的转账操作（即使有 TRANSACTION_READ_COMMITTED）
// 假设在两个并发线程中执行以下代码Connection con = getConnection();con.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED); // 不安全con.setAutoCommit(false);try (Statement stmt = con.createStatement()) { // 1. 读取余额 ResultSet rs = stmt.executeQuery("SELECT balance FROM account WHERE accountId = 1"); if (rs.next()) { int balance = rs.getInt("balance"); int requestedAmount = 100; // 假设请求扣款100 if (balance >= requestedAmount) { // 2. 更新余额 int newBalance = balance - requestedAmount; stmt.executeUpdate("UPDATE account SET balance = " + newBalance + " WHERE accountId = 1"); con.commit(); System.out.println("扣款成功，新余额: " + newBalance); } else { con.rollback(); System.out.println("余额不足。"); } }} catch (SQLException e) { con.rollback(); e.printStackTrace();} finally { con.setAutoCommit(true); con.close();}
在 TRANSACTION_READ_COMMITTED 下，两个事务可能同时读取到相同的初始余额，然后都尝试扣款，导致最终余额错误。
乐观锁机制
为了在某些情况下避免 SERIALIZABLE 的性能开销，可以采用乐观锁。乐观锁不依赖数据库的显式锁定，而是在更新数据时检查数据是否已被其他事务修改。
实现方式：通常通过在表中添加一个版本号（version）或时间戳（last_updated_at）字段。更新时，检查该版本号是否与读取时一致：
UPDATE accountSET balance = ?, version = version + 1WHERE accountId = ? AND version = ?;
如果 WHERE 子句匹配失败（即 version 不再是读取时的旧值），则说明数据已被修改，当前事务需要回滚并重试。
现代化数据访问框架
直接使用JDBC进行数据库操作，尤其是在处理事务、并发和错误重试时，会非常繁琐且容易出错。因此，强烈建议使用现代化数据访问框架。
JDBC的局限性
样板代码： 大量的 try-catch-finally 块、资源管理和手动结果集处理。错误处理： 需要手动解析 SQLException 的状态码来判断是否需要重试。事务管理： 手动 commit() 和 rollback() 容易遗漏。
JDBI和JOOQ简介
JDBI： 一个轻量级的Java数据库访问库，提供了比JDBC更友好的API，支持声明式事务、易于映射结果集到Java对象。它允许你以更简洁、更安全的方式编写SQL。JOOQ： 一个强大的代码生成器和类型安全的SQL查询API。它将SQL查询转换为Java代码，提供编译时检查和强大的DSL（领域特定语言），非常适合复杂的查询和事务。
这些框架通常内置了对事务管理、重试机制（特别是针对 SERIALIZABLE 失败）和乐观锁的支持，极大地简化了开发工作。
使用框架处理事务和重试的优势
以JDBI为例，它允许你通过Lambda表达式定义事务，并可以配置自动重试逻辑：
import org.jdbi.v3.core.Jdbi;import org.jdbi.v3.core.transaction.TransactionIsolationLevel;public class JdbiExample { public static void main(String[] args) { // 假设已经配置好Jdbi实例，连接到Derby服务器 Jdbi jdbi = Jdbi.create("jdbc:derby://localhost:1527/C:DATABSE_SUBVERe", "josh", "1234"); // 注册插件以支持事务和重试 jdbi.installPlugins(); try { // 使用JDBI的事务API，并指定SERIALIZABLE隔离级别 // JDBI可以配置自动重试逻辑，处理SerializationFailureException jdbi.useTransaction(TransactionIsolationLevel.SERIALIZABLE, handle -> { // 模拟转账操作 long accountId1 = 1; long accountId2 = 2; int amount = 50; // 获取账户1余额 int balance1 = handle.createQuery("SELECT balance FROM account WHERE id = ?") .bind(0, accountId1) .mapTo(Integer.class) .one(); if (balance1 < amount) { throw new IllegalArgumentException("账户1余额不足"); } // 更新账户1 handle.execute("UPDATE account SET balance = balance - ? WHERE id = ?", amount, accountId1); // 更新账户2 handle.execute("UPDATE account SET balance = balance + ? WHERE id = ?", amount, accountId2); System.out.println("转账成功: 从账户" + accountId1 + "到账户" + accountId2 + "转账" + amount); }); } catch (Exception e) { System.err.println("转账失败: " + e.getMessage()); } }}
通过JDBI，事务管理变得更加简洁，并且可以集成重试策略，优雅地处理 SERIALIZABLE 隔离级别可能引发的并发异常。
总结与最佳实践
要实现Java桌面应用的多用户并发访问单一数据库，请遵循以下最佳实践：
使用客户端/服务器模式： 这是处理多用户并发访问的根本解决方案。将数据库（如Derby、PostgreSQL、H2）配置为独立的服务器进程。避免嵌入式模式下的多JVM访问： 嵌入式数据库通常不适用于多个独立的应用程序实例同时访问同一数据文件。解决类路径冲突： 原始问题中的 sealing violation 通常是由于类路径中存在重复或不兼容的数据库驱动JAR包。确保只引入一个版本的数据库驱动。选择合适的事务隔离级别： 对于读写操作混合的业务逻辑，TRANSACTION_READ_COMMITTED 可能不足。TRANSACTION_SERIALIZABLE 提供最强的数据一致性保证，但需要实现事务重试机制。考虑乐观锁： 作为 SERIALIZABLE 的补充或替代，乐观锁可以有效处理并发更新，尤其是在冲突不频繁的场景。采用现代化数据访问框架： 放弃直接使用原始JDBC，转而使用JDBI、JOOQ等框架。它们能极大地简化事务管理、并发控制和错误处理，提升开发效率和代码质量。
遵循这些指导原则，您将能够构建出健壮、高效且能够支持多用户并发访问的Java桌面应用程序。
以上就是如何实现多连接访问单一数据库：Java与Derby实践指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/972899.html
微信扫一扫 
支付宝扫一扫 
