问题
I am making a banking application and not able to decide which will be a better approach to handle fund transfer transactions. Using SQL may need rewritting code if the database changes. Using pure Java to handle will make it little more complex in terms of locking the accounts for the transactions. What is the best practice for this scenario?
PS - please consider a distributed application server in this case.
回答1:
Any application, that leaves the DB in a possibly inconcistent state on hard crash, is unfit for banking use. Applications, that leverage so called "Java Transactions" are part of this group.
Any serious banking application will have all writing processes encapsulated into a server-side capsule (read: stored procedure) and not allow any write access to any table. Read access will be served by a mixture of stored procedures and views.
Together with a crash-resistant RDBMS, this guarantees all-or-nothing handling of jobs.
回答2:
All participating resources (including your database as well as any other endpoint or middleware) must also join the same transaction. A transaction is nothing that ends at the boundaries of a component, it spans all involved components in the system. Otherwise, it's no transaction. There should be a driving component, which is usually your own code or some middleware, which starts and commits/rollbacks a transaction. Anyone else joins in. They idea of a transaction is, to reverse the actions of all involved components, if something fails (and to hide already-happened actions to anyone outside the transaction until it is successfully committed). My answer would be: You need both, database and application level transactions, because a transaction involves all participating components.
来源：https://stackoverflow.com/questions/26327065/which-is-better-sql-transaction-or-java-side-transaction-for-an-banking-applica