Vista is a very different operating system than XP in many ways. A lot more happens on the OS; for example there're more services in the system, many of them index data. There's also more code in the system for keeping old versions of data around (snapshots)
that is active - it allows you to revert system changes.
Based on our performance measurements the cost of transactions in the filesystem is quite small (under 2% in the worst case) when transactions are not being used.
Sorry I missed you in Sao Paulo. I really enjoyed Brazil and Sao Paulo in particular.
You asked some really good questions. Let me try to address them:
1) TxF supports committed read isolation. That means you always get the most recently committed data. When read-only handles are opened in a transaction their "view" is decided at the time of the open based on the "most recently committed rule". All reads on
that handle are set to return that view for as long as the handle is kept open. Other transactions are free to update the file as many times as they like.
When read-only handles are opened outside of any transaction the view is decided the same way, but it's not frozen for the duration of the handle - it's changed if some transaction commits a change. This is designed to be compatible with a non-transaction-aware
applications that (when they share with writers) expect to see changes.
Directory queries ("ls", "dir" etc) always show the most recently committed directory contents as of the time the API is called. Again, the directory can be changed concurrently by other transactions by adding and deleting files.
The main thing that comes out of this is that TxF supports concurrent reads while transactions change contents. So, you could update your web-site in a transaction and the reads will get the old view until commit time. At the time of the commit you'd need to
prevent reads so as not to race with it.
Change notifications and the NTFS USN journal entries are also isolated so that they only show up after commit.
You're right about the change in our APIs in RC1. Previously, you could have an ambient transaction and all your NTFS and registry operations would be a part of the transaction. That was a very easy model to get used to and start programming with! The problem
with it was that it was also easy to accidentally include operations you didn't really intend to include in the transaction. This was particularly true programming at higher ends of the programming stack (COM+ and .Net) since many of those components themselves
use the Windows registry itself, and it was very difficult for a programmer to know when/if lower level registry operations were getting included.
So, we decided to make the model explicit. Now we have versions of about a dozen file APIs and some registry APIs that explicitly take the transaction parameter. This way you know exactly what you're transacting, and are much less likely to get hard to debug
We feel that this model is a lot more transparent in its contract and hopefully much less confusing.
We'd love to hear feedback on this. One thing we have heard is that people would like to have the transaction present in the thread environment (but not applied to operations). That way app writers have much less of a burden keeping track of it.
Yes it's similar to the promotable transactions in ADO.NET, except that the lightweight TM is the LTM which directly delegates to KTM when the transaction spans kernel resources only. This way if you start a transaction in .Net and work on a file in NTFS in
that transaction you don't pay for the DTC overhead (process switch). DTC automatically gets enlisted in the transaction if non-kernel resources like SQL get included in the transaction. This happens seamlessly from the application's point of view.
KTM is a fairly lightweight transaction manager and is designed to serve the needs of the kernel resources directly, as well as interface with DTC for broad transaction support.
I'm not quite sure how to characterize DTC's performance. I guess it depends on what you're using it for and what the point of comparison is.
You're welcome! These are good questions. My email address is firstname.lastname@example.org. Feel free to send mail if you'd like to converse.