wood burning stoves 2.0*
The moose likes JDBC and the fly likes What is the practical use of TRANSACTION_REPEATABLE_READ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "What is the practical use of TRANSACTION_REPEATABLE_READ?" Watch "What is the practical use of TRANSACTION_REPEATABLE_READ?" New topic
Author

What is the practical use of TRANSACTION_REPEATABLE_READ?

Ipsita Naravane
Greenhorn

Joined: Dec 27, 2000
Posts: 29
I know that it ensures, that reading the same field twice should always result in the same value being read except when the transaction itself has changed the value.

But what I don't get is why would one want to read the same data twice, vs. reading it once and storing it in some memory location for future use? wouldn't that be faster?

Also, isn't it emplemented through row-level locking? whereas READ_SERIALIZABLE has table locks right? so does this mean that all Isolation levels really provide is different granularity locking?
Scott Johnson
Ranch Hand

Joined: Aug 24, 2005
Posts: 518
TRANSACTION_SERIALIZABLE does not allow other users to insert rows that would affect the current transaction's results. TRANSACTION_REPEATABLE_READ does allow those inserts.

For example, this might be useful in a banking application. If one user is updating the status on an account, other users shouldn't be able to insert transactions until the update is complete because the fee structure might be changing. [It's a contrived example, I know.]


so does this mean that all Isolation levels really provide is different granularity locking?


It's a bit more than granularity. The isolation level sets the locking behavior -- what gets locked and what locks you will honor.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What is the practical use of TRANSACTION_REPEATABLE_READ?
 
Similar Threads
Batch update returned unexpected
Threads and infinite loop
JDBC manually commit
IS the locking mechanism in the EXAM CRAM2 book wrong
Multi-threading programming: we do not need lock() unlock() at all