READ_UNCOMMITTED vs No transactions?

Question

What\'s the difference between executing SQL outside of a transaction versus executing it under READ_UNCOMMITTED isolation mode?

Clarification: I\'m

Answer 1

TRANSACTION_NONE means 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 setTransactionIsolation method:

Note that Connection.TRANSACTION_NONE cannot be used because it specifies that transactions are not supported.

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_UNCOMMITTED still 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_NONE is a free for all - no one gets isolation from anything.

Answer 2

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).