Re: Transaction management in Ozone

On 7-7-2004 9:03, Leo Mekenkamp wrote:
> 
> Yes, but there is no need to use that transaction API, since ozone has
> its own transaction management system. If an ozone transaction has not
> completed, then it will get rolled back by restoring shadowed data.

The problem here is that your transaction API has no guarantee that the 
data is actually written to disk, since Java doesn't allow you to call a 
"fsync" (afaik, although that is, due to harddisk caches, still no hard 
guarantee).
So whenever your transaction-manager thinks it has written something to 
disc, it may not have been written yet, even the seperate steps of a 
two-phase commit may not have been written while the TM thinks they have.

> Al long as the OS/filesystem handles write actions sequentially without
> changing their order, then I do not see why not.

Afaik there is no guarantee that writes to different files (or even 
blocks?) are done sequentially... They may be rescheduled to allow 
better (write) performance, as long as the data that was supposed to be 
written before a certain action on the same array, is written.

> The easiest solution is using a UPS. IMHO every (serious) server should
> have power-backup. And of course a stable OS; I for one do not consider
> Windows to be stable enough.

Using UPS and a stable OS doesn't free you from crashes. Accepting that 
crashes can occur, in rare cases, is much better than trying to deny 
them or point out faulty components (OS, hardware, serveradmins) that 
where supposed to have been replaced ;)
We have expensive (in x86-terms) hardware, slackware linux as OS, 
running in a datacenter with power backup etc etc, but there still are 
crashes... Should we replace the hardware by even more expensive Sun or 
IBM Unix-servers? Or should we accept the fact that there may occur 
crashes so now and then? :)

My point is that one shouldn't expect _too_ much from the underlying 
system, but since you can't prevent everything, you may "ignore" a few 
rare cases.

> The problem (IIRC, someone please step in here
> when I am wrong) is when a crash occurs in that last phase; when the
> server comes back up, it will restore all shadow clusters. Since a
> transaction may span several clusters, some clusters shadows may have
> been deleted, others not.

As said, the transactionmanager may be thinking a write is completed on 
disk, while it is not. As long as that is possible, there aren't any 
solutions possible that are completely safe, I think.

Btw, have a look at PostgreSQL's MVCC-system (which is basically the 
same as Oracle's system), it uses different versions of each record for 
every change. So whenever a transaction did not complete, one simply 
uses the previous version of a record... The restore-process is a matter 
of reading the logfile and have a look at which transactions were 
completed and thereby which recordversions are the latest to use.

The problem with this system is that you don't have an actual knowledge 
of what the "current" database is, you'd be looking at the "most recent, 
save versions". And you need a way to remove old versions which are 
definitely not used anymore.

A bit more information: 
http://www.developer.com/net/vb/article.php/877181 and 
http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html

Best regards,

Arjen



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com