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
