After reading few documents regarding transaction, I'm totally confused now. Let me first explain my scenario.
I've a batch read which takes up around 3 minutes to read the data (SELECT) query from a table. And at the same time another thread tries to perform INSERT/UPDATE/DELETE. It was throwing an error, saying "could not acquire transaction" (because my datasource had a default transaction of 8 (SERIALIZABLE)).
To allow the INSERT/UPDATE/DELETE to execute I set the transaction to READ_UNCOMMITTED (that no lock at all (read/write/range)). But when I executed my program it threw an error saying that the only supported transactions are READ_COMMITTED and SERIALIZABLE.
When I further investigated I found the Oracle has introduced transaction isolation type snapshot isolation which virtually eliminated repeatable reads and dirty reads by taking snapshot of the database during transaction, there by giving consistent data.
From above statement I could use transaction type of READ_COMMITTED however Wikipedia totally confused my understanding till now with the below statement:
Snapshot isolation is called "serializable" mode in Oracle[2][3][4] and PostgreSQL versions prior to 9.1,[5][6][7] which may cause confusion with the "real serializability" mode. There are arguments both for and against this decision; what is clear is that users must be aware of the distinction to avoid possible undesired anomalous behavior in their database system logic.
So now my questions are:
1.READ COMMITTED isolation level: It's the default level. Each query(within transaction) could see only data committed before that query started. So, if you run the same query twice in the same transaction, you could see different results and phantoms.
SERIALIZABLE isolation level: Each query(within transaction) could see only data committed before that transaction started, plus changes made in the transaction itself. So, there are no phantoms here.
2.In Oracle snapshot isolation is called serializable. So, it's the same thing. Oracle will throw error when serializable transaction tries to update or delete data modified by another transaction that commits after the serializable transaction began.
Actually, more info could be found here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With