| Optimistic locking works on the assumption that there will be
relatively few conlicts between transactions. It saves time by taking
out a minimal number of locks (or no locks at all). If any conflicts
are detected during the transaction, then the transaction is usually
aborted. The exact details depend on what optimistic locking
techniques are used.
This means that optimistic locking is usually a win when you have
little contention between transactions. It is usually a lose if you
have more than a "moderate" amount of contention between transactions,
since you spend a lot of time either aborting/restarting transactions
or resolving the conflicts.
You can argue that ALG means that Rdb/VMS allows a user to use an
optimistic locking techinique, but I believe that people who support
more radical techiniques would deny this. ALG is optimistic in that
it tries to take out a minimal number of locks at large levels of
granularity. It takes out more locks at lower levels of granularity
only if there is contention between transactions the higher levels.
This is a win in low contention environments since fewer locks are
taken out than would normally be required. It is a lose in high
contention environments, since transaction spend a lot of time getting
locks at increasingly lower levels of granularity...it would be faster
to just get locks at the low level of granularity and not bother
adjusting lock granularity.
It's usually not very hard to come up with an eample of where a
particular optimistic locking technique is bad. Luckily, Rdb/VMS
allows users to enable or disable ALG for a database. They can either
have "optimistic" or "non-optimistic" locking depending on their
workload.
|
| First, the correct term is "optimistic concurrency control". "Locking"
is a technique for implementing concurrency control, and not the only
technique. Rdb's carryover locks, ALG, etc. may indeed be "optimistic"
locking algorithms, but they aren't optimistic concurrency control in any
way. Rdb retains the architecture that all objects which we touch must
be locked (in some fashion) against incompatible access, a pessimistic
technique.
Optimistic concurrency control algorithms were developed for use in
distributed database systems where, it was felt, the cost of
communications made traditional concurrency control techniques, such as
locking, too expensive. In such an environment, it was felt that the
cost of aborting a transaction on a conflict was lower than the cost of
locking, IFF conflicts were infrequent. Clearly, as Jim mentioned, if
conflicts are relatively common then you end up aborting lots of
transactions and the costs rise dramatically. Also if you use the
technique locally, where locking costs are relatively low, then aborts
become more expensive relative to the cost of locking and optimistic
concurrency control techniques become less interesting.
Interbase is a re-implementation (some wouldn't be so kind) of Digital's
Rdb/ELN. There are three drawbacks, beyond the general problems of
optimistic concurrency control, with its implementation. First, the
techniques it uses PRECLUDES Index-Only access. This is because the
index does not necessarily point to the most up to date copy of the
record. The index points to a chain of record versions which you must
search to find the most recently committed version. Second, it doesn't
rationally implement Degree 3 (a.k.a. Isolation Level 3) consistency.
When you request Degree 3 consistency, it SINGLE THREADS all transactions
through the database by locking the entire database for the duration of
the transaction. Third, there is extra overhead in cleaning up the
record version chains and a single contention point where the commit
status of all transactions is maintained, so it should have significantly
more internal overhead than Rdb/VMS V4.1.
Optimistic concurrency control was pretty much rejected by the
distributed database researchers as a general solution to the concurrency
control problem. They found that FOR THE GENERAL CASE, it was worse than
traditional locking while for special cases it was better.
I believe that any real claim of benefit that Interbase has is that they
can do Degree 2 (Isolation Level 1) transactions pretty well (see
previous postings here, or in the Rdb wish_list conference for a
description of isolation levels) while Rdb hasn't implemented this
feature yet. When Rdb has Isolation Level 1 support, the only thing that
Interbase will have is a neat sounding buzz phrase.
Hal
|
| I assume Interbase works approximately like this:
Every new or modified record stored into the database is tagged with
a transaction number. No write locks are taken out. The system keeps
track of the tags of all records read. At the end of a transaction, the
system looks at the collection of values to determine whether there is
a consistent ordering of all the concurrent transactions that makes
them appear to have executed in order. (This can require waiting, in
hopes that some other transaction aborts.) If there is no such order,
the current transaction aborts; otherwise it commits.
The flaw in that approach is that to get true serializability, you also
need to notify later writers about records you've read. I assume Interbase
provides true serializability only with relation-level locks.
Rdb's approach, where you hold locks to ensure concurrent transactions don't
do anything bad, is called "pessimistic" (at least by advocates of optimistic
locking). ALG is, if anything, more "pessimistic" since it locks more of the
database -- at least in an advisory way.
|