Hi,
I tried to send this question already from the google groups website.
But since I got no answer I am not sure if the question got through.
Anyway here's the question.
You have (Thomas) made clear that durability is not achieved without
resorting to some extreme measures, external to database.
All fine and good.
But this raises the issue whether the durability issue raises the issue
of consistency also.
Example:
A table has some constraints defined.
When inserting a new tuple (let's call it NT) the constraints reject the
insert.
So one deletes a row (let's call it OT).
Then tries to insert NT again and this time the insert is succesful
(constraints are satisfied).
Now comes the server crash and some commits are lost.
The issue is:
Can I be sure that if the delete of OT is lost then also the insert of
NT is lost?
Because if only delete of OT is lost the db is recovered to an
inconsistent state.
The question becomes a question of whether commits are serialized
somehow when writing them to transaction log.
These two different operations could be in different transactions.
Sidenote: This issue has nothing to do with the concurrency modes like
READ_COMMITTED etc.
It is clear that consistency can only be preserved if transactions are
defined as SERIALIZABLE.
This concerns just whether the order of transactions are maintained all
the way down to disk.
- Rami Ojares
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
