READ_UNCOMMITTED 与无事务？
在事务外部执行 SQL 与在 READ_UNCOMMITTED 隔离模式下执行 SQL 之间有什么区别？
澄清：我试图理解 java.sql.Connection.TRANSACTION_NONE 和 java.sql.Connection.TRANSACTION_READ_UNCOMMITTED
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
TRANSACTION_NONE 表示连接根本不支持事务，任何在该连接上强加事务语义的尝试都会失败。我看不出这有什么用处，除非您使用“假”数据库（例如 CSV 文件）。
另一方面，READ_UNCOMMITTED 表示该连接正在使用事务，并且将能够从其他连接的未提交事务中读取数据。正如@Pax 所说，这应该非常谨慎地使用。
另请注意
setTransactionIsolation方法：因此，您不能强制连接使用
TRANSACTION_NONE- 连接要么支持事务，要么不支持事务，如果不支持，您就不能乱用此方法。READ_UNCOMMITTED仍然意味着您正在进行事务。您仍然可以获得原子写入，并且其他事务仍然与您的写入隔离。然而，您的交易并不是与其他人的交易隔离的。TRANSACTION_NONE对所有人都是免费的 - 没有人可以与任何事物隔离。TRANSACTION_NONEmeans that the connection does not support transactions at all, and any attempt to impose transaction semantics on that connection should fail. I can't see this ever being useful, except perhaps in cases where you're using a "fake" database, like CSV files.READ_UNCOMMITTED, on the other hand, means that the connection is using transactions, and will be able to read data from other connections' uncommitted transactions. As @Pax said, this should be used with extreme caution.Note also the
setTransactionIsolationmethod:So you cannot force a connection to use
TRANSACTION_NONE- the connection either supports transactions or it doesn't, and if it doesn't you can't mess with this method.READ_UNCOMMITTEDstill means you're in a transaction. You still get atomic writes, and other transactions are still isolated from your writes. However, your transaction is not isolated from other peoples'.TRANSACTION_NONEis a free for all - no one gets isolation from anything.READ_UNCOMMITTED（或脏读）将为您提供有关尚未完成的事务的信息。
这通常不是一个好主意，因为检索到的信息可能不一致。我们用它来避免报告应用程序中的僵局，其中稍微偏离的数据并不重要，但是，如果您完全关心准确性（例如向人们收费或银行业务），我不会这样做。
在事务之外执行 SQL（我假设此处进行更新）实际上应该是不可能的。 ACID 要求通常需要事务，即使是最简单的更新 - 您可能不会显式开始或提交事务，但我保证它会在幕后发生（至少对于一个像样的关系 DBMS 来说）。
READ_UNCOMMITTED (or dirty reads) will give you information about transactions that have yet to be completed.
It's not usually a good idea since the information retrieved may be inconsistent. We've used it to avoid deadlock in reporting applications where slightly-off data doesn't matter but, if you care at all about accuracy (like charging people money, or banking), I wouldn't do it.
Executing SQL outside of a transaction (I'm assuming updates here) should not really be possible. The ACID requirements generally need transactions even for the simplest update - you may not explicitly BEGIN or COMMIT the transaction but I'll guarantee it'll be happening under the covers (at least for a decent relational DBMS).