本文旨在解决java桌面应用中，多个用户或进程同时访问单一数据库（特别是嵌入式derby）时遇到的并发问题。我们将深入探讨嵌入式数据库的局限性、推荐使用专业的数据库服务器、讲解事务隔离级别（尤其是`serializable`）和乐观锁机制，并建议采用jdbi或jooq等高级jdbc框架来简化并发编程，同时提供解决常见`securityexception`的方案。
在Java桌面应用中，使用如Apache Derby这类嵌入式数据库（Embedded Database）时，一个常见的误解是它能够像客户端-服务器架构的数据库一样，天然支持多个独立的应用程序实例（即多个JVM进程）同时访问同一个数据文件。然而，这并非嵌入式数据库的设计初衷。
核心问题： 嵌入式数据库通常以“in-process”模式运行，意味着数据库引擎直接在应用程序所在的JVM中启动。在这种模式下，数据文件被当前JVM独占。当第二个独立的应用程序实例（另一个JVM）尝试连接到同一个数据文件时，它会发现文件已被锁定，从而导致连接失败或抛出异常。这与事务隔离级别或行级锁定无关，而是数据库引擎的文件系统访问机制所决定的。
你遇到的 java.lang.SecurityException: sealing violation 错误，虽然直接原因通常是类路径中存在多个版本的Derby JAR包导致的包密封冲突，但其深层原因往往是尝试以不当方式（即多个JVM直接访问同一个嵌入式数据文件）实现多用户访问。
要实现真正的多用户、多进程并发访问，最根本且推荐的解决方案是采用标准的客户端-服务器（Client-Server）数据库架构。
立即学习“Java免费学习笔记（深入）”；
将数据库引擎作为一个独立的服务器进程运行，应用程序则作为客户端通过网络（通常是TCP/IP）连接到这个服务器。
推荐选项：
实现方式：
// Derby 网络服务器模式示例 String host = "jdbc:derby://localhost:1527/C:\DATABSE_SUB\VERe"; // PostgreSQL 示例 // String host = "jdbc:postgresql://localhost:5432/your_database_name"; String uName = "josh"; String uPass = "1234"; con = DriverManager.getConnection(host, uName, uPass);
通过这种方式，无论有多少个Java桌面应用实例运行，它们都将作为独立的客户端连接到同一个数据库服务器，由服务器负责管理并发访问、锁定和数据一致性。
虽然理论上可以设计一个Java应用作为数据库的“代理”或“服务器”，由它独占嵌入式数据库文件，然后通过本地TCP/IP或其他IPC机制与同一台机器上的其他Java应用通信。但这种方案极其复杂，需要大量的自定义代码来处理通信、连接管理、请求转发等，且缺乏成熟的库支持，不推荐在实际项目中使用。
一旦采用了客户端-服务器架构，数据库本身就能处理多用户并发。此时，事务隔离级别和并发控制策略变得至关重要，以确保数据的一致性和完整性。
你尝试设置 con.setTransactionIsolation(TRANSACTION_READ_COMMITTED); 这表示“已提交读”隔离级别。虽然它能防止脏读（Dirty Read），但它无法解决以下问题：
对于需要高数据一致性的业务逻辑（例如银行转账），这些问题是不可接受的。
SERIALIZABLE（可串行化）是最高的事务隔离级别，它确保并发事务的执行结果与它们串行执行的结果一致。这意味着它能有效防止脏读、不可重复读和幻读。
示例：ATM取款逻辑的并发问题
考虑一个简单的ATM取款伪代码：
AccountId accountId = cardReader.getAccountIdFromInsertedCard();
int requested = askUserToPickAmount();
db.startTransaction(); // 开启事务
try {
// 1. 查询余额
int balance = db.select("SELECT balance FROM account WHERE accountId = ?", accountId).singleInt();
// 2. 检查余额
if (balance < requested) {
throw new InsufficientBalanceException();
}
// 3. 更新余额
int newBalance = balance - requested;
db.update("UPDATE account SET balance = ? WHERE accountId = ?", newBalance, accountId);
db.commit(); // 提交事务
cashEmitter.emit(requested); // 出钞
} catch (InsufficientBalanceException e) {
db.rollback(); // 回滚事务
// 提示余额不足
} catch (SQLException e) {
db.rollback(); // 回滚事务
// 处理其他数据库错误
}在 TRANSACTION_READ_COMMITTED 级别下，如果两个用户同时尝试从同一个账户取款，并且初始余额足够支付两次取款，但不足以支付一次取款后剩余的余额，可能会导致超支。例如，账户有100元，两人同时取款60元。在 READ_COMMITTED 下，两人都可能看到100元，然后都判断余额充足，最终都成功取款，导致账户变为-20元。
使用 SERIALIZABLE 隔离级别可以避免此类问题。数据库会确保事务的原子性、一致性、隔离性和持久性。
SERIALIZABLE 的挑战与乐观锁：SERIALIZABLE 隔离级别虽然提供了最高的数据一致性，但代价是可能降低并发性能。当多个事务冲突时，数据库可能会抛出 SQLException，指示需要重试（例如，死锁或序列化失败）。这意味着你的应用程序需要实现重试机制。
乐观锁（Optimistic Locking）： 相比于传统的悲观锁（如行级锁定，它会在读取时就锁定资源），乐观锁是一种更现代、更具扩展性的并发控制策略。它假设冲突不常发生，因此在读取数据时不加锁，而是在更新数据时检查数据是否已被其他事务修改。这通常通过在表中添加一个版本号（version）或时间戳字段来实现。
乐观锁伪代码：
// 假设 account 表有一个 version 字段 // SELECT balance, version FROM account WHERE accountId = ? // 更新时： // UPDATE account SET balance = ?, version = version + 1 WHERE accountId = ? AND version = oldVersion // 如果更新失败（影响行数为0），则表示数据已被其他事务修改，需要重试整个操作。
结合 SERIALIZABLE 隔离级别和乐观锁，可以在保证数据一致性的同时，提高系统的并发能力。
直接使用JDBC API进行数据库操作，尤其是在处理事务、并发和错误重试时，代码会变得非常冗长且容易出错。强烈建议使用更高级的JDBC抽象框架。
推荐框架：
这些框架不仅提供了更友好的API，还内置了对事务管理、批处理、结果集映射等功能的良好支持，能够有效降低并发编程的复杂性。
这个异常通常发生在Java模块系统（Java 9及更高版本）中，当同一个包（例如 org.apache.derby.security）被加载了两次，且其中一个JAR包被声明为“密封”时。这通常是由于类路径中包含了同一个库的多个版本或不同来源的JAR包。
解决步骤：
这个错误与数据库的并发访问策略本身无关，但它会阻止应用程序正常启动并连接到数据库。
实现Java桌面应用的多用户并发访问，关键在于采用客户端-服务器架构的数据库，而非直接使用嵌入式数据库文件。选择如PostgreSQL、MySQL或Derby网络模式等专业的数据库服务器，可以有效解决多进程访问冲突。在并发控制方面，优先使用SERIALIZABLE 事务隔离级别配合乐观锁机制，以确保数据一致性。同时，为了简化开发并提高代码质量，强烈推荐使用JDBI或JOOQ等高级JDBC抽象框架。最后，务必检查并解决类路径中的SecurityException: sealing violation问题，确保应用程序能够正常启动和运行。
以上就是处理Java桌面应用多连接数据库的策略与实践的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
660
收藏
