if Oracle block read and write, so we will never have diry read. Because everything is serialized. if more than one user come to access the database, we dont need to put transaction to protect our code. Because finally the database will serialize everything.
Don't you guys think this will be the solution for Oracle. Oracle is famous for its concurrency access.
on the contrary, to avoid dirty read,non-repeatable read,phantom read, we must use transaction to protect our sql execution in java,even for query. let alone you write sth in db concurrently.
Then you definitely need to transact your "write" SQL in java.
If we go deeper into Oracle, even two transacted "SQL write" statements try to access the same row, which will still result into an error. of coz you need to set Oracle isolation level as SERIALIZABLE.
If A is doing a transaction and not yet commited, is it possible for B to read his data in DB?
Answer this question
and I will tell you how it works inside Oracle.
btw: assume A and B are accessing the same data in DB
if read lock can be shared, which means read doesnt block write, then for the normal DB, the dirty read will happen?
but how does oracle avoid that happened?
in fact, the concept is same for the concurrency control whatever it happened in memory or in DB domain. in java, it is thread-safe problem if you have only one machine. in DB, it is a concurrency access issue for read and write.
Normal DB they block one operation against other to avoid dirty read, repeatable read,phantom read. But Oracle has better solution to solve that---multi-version control. in fact, it is the same solution also applying for SVN.