db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby architecture/design documents
Date Mon, 07 Feb 2005 19:22:13 GMT
The simple answer is that every updating operation that comes through
store first creates a log record and writes it to the logging system,
and then applies the change using the log record to the page in
question.  What looks like a single sql operation may be many updating
operations in the store, so in many cases if an error happens there
may already be log records generated and part of error handling will
be to undo all the log records associated with the current statement.

Let me explain what I think happens with a unique key constraint, since
I know that one.  I am not as sure about the foreign key and check
constraint as those are more enforced above store.

unique key constraints are enforced in derby by creating a unique
btree index.

1) To update a column from A to B, language would first find the row
in question either by scanning or using an index if the query allowed.
2) language would call store to update the collumn in the base table
row from A to B, this will generate a log record.
3) language will now check to see if any indexes need to be updated, in
this case there will be a unique index on the column.
4) language will delete the row in the btree for this index, this will
generate a log record.
5) language will attempt to insert a new row into the btree with the new
column value, this insert will fail as there is already one.  This will
not generate a log record as the btree insert fails before it gets that
6) language gets the error and generates a statement level error, and
will generate a statement level abort which will cause undo of this
statement.  These will generate compensation log records.

RPost wrote:

>>"Dibyendu Majumdar" wrote:
>>. . . The forward change from A to B (redo) and the reversal of B to A
> (undo) are both recorded as updates to the system.
> At what point does a change from A to B cause the creation of a log/recovery
> record?
> For example, if a column has a current value of A and the change to B would
> cause a violation of a check, unique or foreign key constraint will a log
> record be created or will the change have already been rejected?
> There will potentially be more complicated scenario's where a change causes
> a trigger, or other side effect, to be executed. Generally speaking, at what
> point do the log/recovery records for these multiple changes get created?
> Only if the attempted changes meet all of the criteria for acceptance? That
> is, only if they would be accepted were a COMMIT to be performed?

View raw message