[OT] transactions, filesystems, databases; ease of use

[Fernando Padilla <fe...@interdimensions.com>]

>Gianugo wrote:
>Fernando Padilla wrote:
>> Sorry for the digression.  But I hold a slightly different view.
>> Filesystems do not have a transactional nor a distributed interface.
>
>And sorry for the disgression, but what about NFS/CIFS coupled with a
>journaled filesystem?
>
>Ciao,
>
>--
>Gianugo Rabellino


:) I meant not to send that email :) and was surprised that I had
inadvertently sent it :) oops.  but now that it's open, I guess we can
indulge in a little academic sparring, but not too much, alright ;)

ps - this is a digression and anyone can easily ignore this ( i hate to 
force my ramble on people ).


transactions: A journaled implementation has nothing to do with 
transactions.  I don't know of any filesystems that allows you to say, 
openTransaction, do a lot of operations, then either rollback, or commit 
all of those operations in an atomic format.  If there is one, I would 
love to learn about it.


I'll give it to you that there are distributed filesystems that are great
solutions to many system requirements - ignoring such issues as
administration overhead and platform dependencies.  But I guess, the
transaction and ACID rules that any "filesystem" lacks is what gets to me.  

So I see Databases filling two roles, an ACID and transactional Data
Storage role, then an optimized/efficient Data Querying role. Filesystems
provide neither of these, by design.

I guess the metaphor is comparing UDP to TCP. Yes, most of the time UDP
will get there, but you would NEVER assume that it will get there 100% of
the time.  If you use the filesystem, most of the time the system will
maintain a coherent view ( data will not be missing and properly
synchronized), but the filesystem NEVER said it would guarantee that for
you; at least not for multiple file operations, etc, etc.


Anyway, this is just academic sparring :)  Programming is sometimes an 
artform, with no blank and white, as to practice, technique and design.  I 
for one am a little lazy, and feel that requiring a database to implement 
ACID transactions for me, and leveraging that for all of the system's data 
storage needs, is a good thing.

UDP is a fine protocol, but everyone feels more comfortable using TCP.  
Because it provides service guarantees that UDP does not.  Because no one
in their right mind would try to reimplement a protocol that has similar
service guarantees as TCP ontop of UDP for each project they work on.  
Because you worry less, your designs have to make less assumptions, and
your implementation is simpler.


But then again, we don't have a Database equivalent of TCP, that provides
efficient service guarantees for any data storage needs.  So I have been
discussing the ideal, maybe unreachable today.  But that is what I hope
Xindice will do.  So as we go and evolve Xindice, and turn it into what it
will become in the future, we shouldn't do things because that is the way
they've been done, we should strive for the ideal, for what we want it to
be.


the sometimes pedantic,
Fernando Padilla