对于银行应用程序，SQL 事务或 Java 端事务哪个更好？

Posted 2023-02-22

【中文标题】对于银行应用程序，SQL 事务或 Java 端事务哪个更好？

【英文标题】：Which is better, SQL transaction or Java side transaction for an banking application?

【发布时间】：2014-12-07 06:07:19

【问题描述】：

我正在申请银行业务，但无法决定哪种方法更适合处理资金转账交易。如果数据库发生变化，使用 SQL 可能需要重写代码。使用纯 Java 来处理在锁定交易帐户方面会稍微复杂一些。这种情况的最佳做法是什么？ PS - 在这种情况下，请考虑使用分布式应用程序服务器。

【问题讨论】：

“更好”怎么样？表现？可维护性？可靠性？

使用纯 Java：这是什么意思？ Java 不是数据库。它不坚持任何东西。使用 JDBC 启动/提交事务与使用 SQL 启动/提交事务是一回事。

表示java代码中的事务-业务逻辑。

更好的意思是事务完整性——正确性。

您无法保证使用“纯 Java”的数据库状态的完整性。数据库是事务性的，这是有充分理由的。当然你绝对需要使用 SQL 事务。

【参考方案1】：

任何在硬崩溃时使数据库处于可能不一致状态的应用程序都不适合用于银行业务。利用所谓的“Java 事务”的应用程序属于该组。

任何严肃的银行应用程序都会将所有写入过程封装到服务器端封装（读取：存储过程）中，并且不允许对任何表进行任何写入访问。读取访问将由存储过程和视图的混合提供。

与抗崩溃的 RDBMS 一起，这保证了对作业的全有或全无处理。

【参考方案2】：

所有参与资源（包括您的数据库以及任何其他端点或中间件）也必须加入同一事务。事务不是在组件边界处结束的任何东西，它跨越系统中所有涉及的组件。否则，就没有交易。 应该有一个驱动组件，通常是您自己的代码或一些中间件，它启动并提交/回滚事务。其他任何人都可以加入。他们对事务的想法是，如果发生故障，则反转所有相关组件的操作（并将已经发生的操作隐藏给事务之外的任何人，直到它成功提交）。 我的回答是：您需要数据库和应用程序级别的事务，因为事务涉及所有参与的组件。