Re: Transaction management in Ozone

PREVIOUS COMMENT
>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).

MY REPONSE
I dont' think this is true. Flush()ing an I/O stream does force a write to disk. It's not a soft flush() , it's hard. 

PREVIOUS COMMENT(S)
>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.

>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.

>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.

MY RESPONSE
My 2 cents: a crash can happen at any (inconvenient) moment; neither the immediacy of a forced write to disk 
nor even the ability to control WHERE on disk the data is written(something Java can not , in fact do) will save 
you in every situation. The solution is not to be found in UPS or other things, the solution is to be found in the way databases
write to the log first, before they write to disk; the way they handle undo and redo on restart (from a crash or power outage) from the log and the maintainence of the log. In a very real sense, the log IS the database and everything else is for us poor limited humans who can't interpret the log too easily. That's the whole *trick* of a database. The log is guaranteed to be ACID, despite the fact that the individual components on which is written and through which it's written can flake, fail and fuimble at any moment. As to how this is acheived, I can only say, it's like magic, only more complicated.
If you're worried about this:

<SNIP>
>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.
</SNIP>

then you're really worried that the log is not being written to and read from properly under all circumstances.


_C
 






-------------------------------------------------------
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