db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Junginger" <Markus.Jungin...@mobilexag.de>
Subject Derby Locking vs. Oracle's and MySQL's
Date Wed, 15 Oct 2008 12:43:31 GMT
Hi,

 

I am using Derby a couple of months now. Before, I usually worked with
Oracle (and some MySQL) DBs. For some reason, starting with Derby, I
became acquainted to DB locking issues. Is it just coincidence, or is
Derby actually trickier than Oracle when it comes to concurrency? I just
didn't have these issues before...

 

After some research, my speculation now is that Derby does never use the
rollback log for SELECTs. Let's say, we do read committed isolation and
transaction tx1 updates an entity (table or row) and stays open for some
time. Now, the entity is locked. When transaction tx2 wants SELECT this
particular entity, it has to wait until tx1 completes and the lock is
freed. Is this correct?

 

I think Oracle handles this differently and tx2 does not even need the
lock for a SELECT (UPDATE's is a different story). Instead, tx2 operates
on the state before tx1 started using the tx1's rollback log.
(http://www.broadh2o.net/docs/database/oracle/oracleLocks.html)

 

I would be very glad if someone could confirm whether my speculations
are correct and that is a major difference in locking mechanisms. Or am
I on the wrong track here?

 

Thanks!

 

Markus


Mime
View raw message