Can I make h2 to fsync before returning from a commit if I set
|WRITE_DELAY to 0?
|- Rami Ojares
What I meant to say is that if you don't have durability of
transactions then you can not quarantee the consistency of the database.
My example revisited:
- Two transactions are committed (T1, T2) = they are written to
transaction log
- Now some buffer on the way (doesn't matter if the buffer is in OS,
SCSI card or inside the drive) holds those 2 transactions.
- Some cache mechanism on the way decides that it is better for
performance to write T2 first and so it is written to disk.
- Power goes off
--> Only T2 was committed --> Database is in inconsistent state.
Therefore durability of the transaction log is of paramount importance.
Reading through Brad Fitzpatrick's blog "diskchecker.pl" I think he
concluded that durability can be had if one turns off hardware
write-caching in the disk.
This is terrible for performance unless there is a raid card that does
the caching and has a nvram-backed cache.
Also caching can be done on OS-level and it can be done quite
efficiently with TCQ for SCSI disks and NCQ for SATA disks.
If the user does not want to call the fsync for his updates often
(because of speed) then he can always choose to not commit his
transactions so often.
I think Brad uses his program to validate that he has a system that is
durable.
This he does because he feels that durability is of primary importance
for databases.
Now I can understand how it makes updates of database faster when you
do not fsync the transaction log after every commit.
But I think that this speed comes with a considerable cost in
consistency.
You wrote on the web:
"Trying to flush hard drive buffers is hard, and if you do the
performance is very bad. First you need to make sure that the hard
drive actually flushes all buffers. Tests show that this can not be
done in a reliable way. Then the maximum number of transactions is
around 60 per second. Because of those reasons, the default behavior
of H2 is to delay writing committed transactions."
I think that if you disable the write-cache in the disk and use recent
linux then fsync does flush buffers.
Or if one uses disk or disk controller that has nvram then both speed
and durability can be had.
It seems that H2 adds yet another cache in the disk writes of the
transaction log
h2 cache -> os/filesystem cache -> disk controller cache -> disk cache.
So finally my question is: What is currently the practical benefit of
h2 cache?
Does it speed up operations if the other caches mentioned above are
turned off?
Because when some of these caches are already in place (most of the
time for people who do not know how to turn them off)
then it seems to me that the h2 cache is redundant.
- Rami Ojares
Let's say I am ok with losing some transactions in the rare case of
server crash. But this issue raises some consistency concerns.
Is it quaranteed somehow, that if the delete of OT is lost also the
insert of NT is lost.
Yes, if you do both within the same transaction. See
http://en.wikipedia.org/wiki/Database_transaction
In other words do the writes to disk get serialized?
I'm not sure if I understand this question, but yes, they are
serialized.
And does transaction concurrency mode have an effect on this?
Usually not, except if you disable locking.
Regards,
Thomas
--
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.
