| Cognos is claiming that StarBase support "the 2-phase commit protocol".
That is exactly correct. They support the protocol, not the
implementation. The way it works is:
I have a transaction that updates a StarBase on node A and
a StarBase on Node B. If either update fails, an error flag gets
set. Then the system manager/DBA gets into the StarBase GFIX utility
and manually rolls back both databases. So, yes it supports 2-phase
commit. But no, the implementation is less than most people expect.
Optimistic locking strategies assume no conflict rather than locking
to prevent conflict. In other words, no delays should be tolerated
for data input. The conflicts are then worked out later. Optimistic
locking strategies are enormously successful in situations where
there is virtually no contention for record access. However, the
fact is that optimistic locking defers rather than eliminates locking
overhead. That is, if conflict does occur, the DBMS then has to
consult its update logs to see what action to take to guarantee
data integrity.
While optimistic locking sounds great (each user has his own
"generation" of the data), something has to resolve the conflicts
present in access contention for records. There is no free lunch.
---- Michael Booth
|
| StarBASE does not support classic optimistic concurrency control. What
they support is a model of the world that assumes the application takes
responsibility for transaction consistency. If you ask the database to
provide the consistency, they degrade to locking up the entire relation
being accessed. Also, their model avoids holding locks on index nodes
(since they aren't needed unless you are trying to provide consistency)
and never uses them as data (ie, no index-only access), so they don't
run into problems with concurrent access to those structures (but they
will do more I/O in cases where other database systems could do
index-only access).
While there are some good ideas in StarBASE (I mean, Rdb/ELN
technology)), it is by no means a new generation of relational database.
In fact, in terms of its meeting various "goodness" criteria for
relational database systems, its in pretty bad shape. It does a poor
job of supporting ACID transactions, having poor performance when
meeting the Consistency criteria and being unable to meet the Durability
criteria due to its lack of AIJ support on VAX. Its SQL implementation
is incomplete, with the DBA basically forced to use the proprietary
language utilities to manage the system. Also, its SQL is not ANSI
compliant. Its support for multi-file databases is weak (being similar
to Rdb/VMS V2.* multi-disk databases except a little more explicit).
Its logging/recovery scheme is not state of the art (ie, no group/fast
commit) requiring more I/O than necessary for update transactions.
Basically, you are getting a lot of marketing B.S.
|
| One of my customer just requested a technical debate to compare
Rdb and Starbase. A technical representative from COGNOS in Ottawa
represented Starbase and I represented Rdb. During the meeting, I've
learned interesting things about Starbase and I figured this note
was a good place to put it. So here it is.
Starbase locking mechanism.
--------------------------
No matter if what they support is really a "classic optimistic concurrency
control", they call it "record versioning". Basically, what they do
is to keep multiple copies of a record in the database, which is a little
bit equivalent to what we do with the snapshot file. Every time a record
is updated, a new version is written to the database, on the same page
as the current record. If they don't fit, they will a be rewritten to
a new page (so he said). Their mechanism allows a transaction to be
written without having to worry about holding read locks for very long
period of time, something we have to do with Rdb within the application
(unless you use Rally, which reads in Read-only mode and starts a
read-write transaction when the user wants to update the record. Rally
will then compare the contents of the record to see if it has changed
and will issue an error if yes, a very nice feature).
An update example will show what they do:
USER A USER B
----------- -----------
reads record
(no read lock is placed on record)
reads same record
(no read lock is placed on record)
updates record
(Starbase writes a new version of the record)
update the same record
(Starbase makes the user wait since a newer version exist)
commit
(Starbase allows the commit)
(Starbase aborts with a deadlock message)
There is no big difference with Rdb in this case other than the fact that
USER A would wait after the Update statement. Assume that USER B
decides not to update the record. This is the case where Starbase makes
it much easier. USER A would not see any interference and his
transaction would complete immediately. With Rdb, USER A would wait
until USER B decide to commit and then release the read lock (PR lock).
If you want to acheive the same thing with Rdb, you have to start
USER's B transaction in read-only mode and then restart it in read-write
mode only if the update is requested (just like Rally). To do that in
3GL (with ACMS for example) is far from being a trivial task.
In reply to -.1:
�they support is a model of the world that assumes the application takes
�responsibility for transaction consistency. If you ask the database to
�provide the consistency, they degrade to locking up the entire relation
�being accessed.
I don't see that Starbase has any problem with transaction integrity
and apparently they do support Degree 3 consistency.
� It does a poor
� job of supporting ACID transactions, having poor performance when
� meeting the Consistency criteria and being unable to meet the Durability
� criteria due to its lack of AIJ support on VAX.
Not true again, since Starbase has AIJ support so transactions will meet
tha ACID test.
Just to mention it, that record versioning feature allows Starbase to
perform transaction recovery without having to use RUJ files for each user.
During recovery, all they have to do is read the database. In case of
a system failure, they have to scan the whole database sequentially with
their GFIX utility in order to recover. That process must be quite slow
for a large database
Large Database support
----------------------
The Cognos representative said that for large databases and TP application,
Rdb would be a clear winner. They don't support multi-file database,
but allow spreading of the database to multi volume, a little bit like
pre v3.0 Rdb, but with more control over placement of the files.
Starbase has to monitoring tools or tuning facility. RMU/SHO STAT
is a great tool and with all the features of the STORAGE MAPS, Rdb
is a clear winner here.
Triggers:
--------
This is another plus of Starbase. They do support triggers for
Insert, Update and Delete. Since this will be available with Rdb v3.1,
there is no big plus here. He said that their next release (V3.0)
will support even better stuff with triggers: something like automatic
generation of triggers according to business rules!
He mentioned that triggers could be used to update the database
through views. I did not quite get how that would work and the
Cognos guy did not seem to know either.
Distributed Databases:
---------------------
They do support 2PC protocol. However, in case of a system failure,
the remote(s) dtabase(s) will have to be recovered manually (using GFIX).
They intend to make it completely automatic with their v3.0 release
due much later this year.
Conclusions:
-----------
Even though Starbase has some nice features, they lack so much in
important areas (such as database tuning and maintenance) that Rdb should
be a winner in most situations. With COGNOS pushing it a lot, we are
seeing more and more competition, especially here in Canada.
I hope this information is accurate and will help us win over Starbase.
Pierre Bourassa
TP/DB Consultant
Canadian regional support
|
| Starbase's "record versioning" doesn't support Degree 3 consistency.
Here's an example that shows why:
Suppose I have a transaction that copies record A to record B, and
another that copies record B to record A. Obviously, if I run either
in isolation, or both sequentially in any order, the result will
be that record A and B are equal. With Starbase, the following
can happen:
Process 1 reads A (gets "a")
(no locking is done, and no
record is made of the fact
that it read this record.)
Process 2 reads B (gets "b")
(no locking is done, and no
record is made of the fact
that it read this record.)
Process 1 writes B = "a"
(prior copy of B kept as
a snapshot. This write doesn't
wait, since there's no way to
tell another process has read it.)
Process 1 writes A = "b"
(prior copy of A kept as
a snapshot. This write doesn't
wait, since there's no way to
tell another process has read it.)
The result is not one that could have arisen from some serial ordering
of the transactions.
Serializability depends not only on doing the right thing with all
the records you write, but also with the ones you read, in case
your updates depend on them (if not, why did you read them?).
The problem is visible any time you have a pair of concurrent
transactions, each writing a record that the other only reads.
For a business example, consider a manufacturing planning system.
I order a new VAX, and you add my order to the system. Your
transaction increments the counts of various componentss on order,
and then checks a table for each component to see when my order could
be completed, and you give me a committed date.
At the same time, someone else is modifying the tables to stretch
out manufacturing some components because we're devoting some resources
to a new product startup. They look at the count of outstanding orders
for each component so they can see if changing the schedule will
impact any customers.
You can guess the rest: The "place order" transaction reads the
old tables, and writes a new count (and gives me a commitment);
the "update tables" transaction writes new tables, but reads the
old count (and so doesn't see the commitment that it's going to
break).
It's also not clear to me what Starbase does when it needs to
visit "all the records" in a relation, at the same time that someone's
storing new records. Any problems here?
The "optimistic concurrency control" algorithms that really work
(provide D3) keep track of which records a transaction has read, and at
the end check to make sure that there is a consistent ordering for
the versions the transaction read and wrote.
I assume Starbase supports the "CONSISTENCY" keyword, and implements
it the way Rdb/ELN does -- by locking relations in PROTECTED mode.
This would work, but is kind of hard on concurrency!
|