gavin wrote:
Sounds like you are talking about what is usually called the "mulit-version concurrency model". Both Oracle and Postgres work this way. Hibernate was architected especially so that you may take advantage of the high scalability of multi-version concurrency model. So Hibernate never does locking in the middle tier.
Multi-version concurrency has nothing to do with occ. In MVC you create copies of the modified data. With occ you have only _one_ version that can be read/written by multiple transactions. An occ database will
never deadlock.
Databases that do occ are e.g.
MimerSQL
www.mimer.com
Frontbase
www.frontbase.com
I'm asking this question because not every library works with occ. Normally you would write
Code:
// For "normal" locking
insertData();
updateDate();
commit();
// With optimistic concurrency control you must write
final int MAXTRIES=3;
int i = 0;
while (i<MAXTRIES) {
insertData();
updateDate();
try {
commit();
break;
}
catch (SQLException e) {
// check if we got a "locking" problem and try again until maxtries
if (e.sqlcode="ROLLEDBACK") i++;
else throw e;
}
if (i == MAXTRIES)
throw new SQLException ("Have tried too much for this transaction!");
}
The code should indicate that code written for "normal" locking will not work without modifications with occ (of course the code is not wrong - it's rather suboptimal).
For a high level description of occ see
http://developer.mimer.com/features/feature_15.htm
There are also some (very old) papers about occ in the VLDB journal.
Login
FAQ
Search
