No isolation violations are allowed using this isolation level. Non-repeatable reads, phantom reads and dirty reads do not occur.

To set the read uncommitted, simply add this row to your DataSource:

<transaction-isolation>TRANSACTION_SERIALIZABLE</transaction-isolation>

We can see the relationship between transaction isolation violations and transaction isolation levels as follows:

We have seen that the serializable isolation is stronger than the others, so someone could ask himself if it is always the correct isolation to configure. The answer is no because concurrency and transaction isolation level are inversely related. The higher the isolation level, the lower the concurrency you have. With low concurrency, the system performances go bad so that the system can support fewer users. Therefore, we need to find a balance between greater performance possible at lower isolation levels and safety of higher isolation levels. Also this choice has an impact on the complexity of the code we write. With higher isolation levels, we must worry less about concurrency issues in our code because the transaction manager is dealing with them for us. With lower isolation levels, we must worry about the isolation violations that we're letting through, consider whether they might actually occur or not, and potentially deal with them ourself in our application code.

In many cases, the isolation level has been chosen for us. For example, if our application works with a single relational database, its transaction manager will have a default isolation configuration optimized by the vendor for typical uses.