I was reading on the different transaction isolation levels, and came up across the SERIALIZABLE
isolation level. I also know that databases such as Postgres, O
It seems to me that SERIALIZABLE can't work in this BUSINESS transaction, because you need to check some conditions after selecting an entity (for example, if an account has enough money). Concurrent transactions can get the wrong value with SERIALIZABLE level, because it holds shared (read) lock for SELECT.
But SELECT ... FOR UPDATE will work properly because it will hold an exclusive lock until the end of a transaction and will force other transactions to wait.
The main difference between SERIALIZABLE and using SELECT FOR UPDATE is that with SERIALIZABLE everything is always locked. Where as with SELECT FOR UPDATE you get to choose what and when you lock.
So if you only want to lock some data, i.e. BankAccount but not other, i.e. Branch, AccountTypes, then SELECT FOR UPDATE gives you much better control, where as SERIALIZABLE would block your entire system because every transaction selected from the ACCOUNT_TYPES table. Also, some transactions may just want to check the balance, so do not need to lock the ACCOUNT table.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Locking