commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels" <>
Subject Re: Future of Transaction subproject
Date Mon, 09 Sep 2013 21:53:26 GMT
Am 09.09.2013, 23:01 Uhr, schrieb TylsBurt <>:
> I am incredulous that nobody wants to know *why* the main target of the
> project (file atomic transactions) cannot be achieved..

Some file operations on some file systems/OS can be atomic (or even  
transactional) - but a lot of them are not accesible from the java class  
library (for example you cannot open a file with O_EXCL).

Real (to other components visible) transactions require special file  
systems (for example TxF NTFS on Windows) which have their own APIs. Using  
pure java the most transacitional semantics could be implemented with  
networked filesystems (speaking NFS, iSCSI or DRDB protocols come to mind).

But on local filesystems, even for native code having a portable crash  
safe io library is next to impossible (especially if you want to also  
address common OS and Disk problems liek write barriers, reordering and  
lying devices).

You can of course simulate some multi operation transactional properties  
(especially if all clients cooperate with the same schema). This is what  
XADisk and other (locking) schemes expect. This might be enough for some  
needs, but it is not what others expect (and most likely does not survive  
all failure modes).

If you only need a transactional storage in a cooperative environment, it  
would be best to use one of the existing RDB MS.

BTW: the discussion thread seems to be 3 years old. I was actually not  
aware of the state of commons transaction.file. The project homepage list  
it as "Dormant", the SVN links exist but dont work. Is there maybe an  
option to have the site to link to "archive" Download and SVN sites  
(removing binaries from the regular dl section)?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message