If something is cool, this is! We’re getting a transactional file system in Windows Vista.
[Update, same day] Clarification: this of course means that we can start using the file system again.
Filed under: Technology
6 Responses
-
Recent Comments
Thomas Drakengren on Lean GTD 2007 ideasmiths on Lean GTD 2007 ideasmiths on Lean GTD 2007 Thomas Drakengren on Lean GTD 2007 ideasmiths on Lean GTD 2007
The way they talk about it, it seems clear to me the focus is on what happens when you press Ctrl-S in Office-like rich client applications, getting rid of all the special cases with temporary files and renaming. The TXF lets you avoid having to write a lot of potentially fragile code for yourself.
Since the transactions are 2PC-enabled, it should also play into the hands of Office as a rich client front end (coordinating local file saves with back office updates). However, I wonder whether Office 12 is still synced with Vista, and whether they really dare go into the file system interactions for the next release: if not, that particular scenario might be delayed several years. Not to mention the huge base of legacy O/S installations which will remain for Vista+8yrs, at least! And, of course, as Pat Helland has pointed out repeatedly, 2PC is the very best existing anti-availability protocol!
Third, I can’t help but wonder whether this may not be a significant simplifier for making highly focused (even application-specific) custom database engines viable, using e.g. XML and whatever query/indexing mechanisms best suits a specific business problem. Today, whenever you need transactionality, you usually end up stuffing the data into SQL Server on the Windows platform at least. Making ACID guarantees in highly concurrent applications isn’t something Random Q Hacker should want to get involved in… no matter how fascinating the problem is compared to the usual humdrum business requirements!
Any other major usage scenarios out there?
Don’t forget the scenario of installing new applications! Did you notice that the Windows Registry will be transactional, too?
Hmmm, yes, that’s at least moderately chilly. But it will take a considerable while to alter or replace the MSI database format and drivers. What happens to MS SMS meanwhile for enterprise deployments?
I’m a bit ambivalent about the registry (no, I didn’t catch that bit): once I thought that was the Solution to Everything(tm); but INI/XML/.config files ain’t all that bad when you look at all the scenarios. I just hope the transactionality is a bit finer grained than at hive level!
Actually application installation has stricter requirements than do transactions: you need to be able to rollback the installation *after* it has completed, too.
Ha, what about this scenario, then?
1) Begin transaction
2) Download and run program
3) Quit program
4) End transaction
No traces left in the system!
Yeah, right, the ultimate ‘software as a service’… Might even be implementable as a reversible computation, where we end up spending no energy, and receiving no benefit whatever!
No ACID transaction is going to help you with that scenario — rather, you are making a requirement akin to the misnamed ‘long running transactions’ (or my favourite synonym, ‘sagas’), waiving isolation and atomicity for a weaker compensating transaction: in this case, uninstallation. No quite the scope of TXF, methinks!
I doubt we’ll ever get away from being haunted by the ghosts of applications past, unless we virtualize everything on our machines. Which we might in the future, once software architecture is overshadowed by the burgeoning discipline of software archeology!
Well, my scenario was a joke, if that wasn’t obvious!
Ha, I’m sure some obscure researcher has already written a paper on transactions and reversible computations…