My Blog is now at http://paulfallon.com

 

 

In my last blog posting, How should we think of Transactions ? I mentioned Volatile transactions and how I currently think they can be perceived in different ways! Do they have ACID, ACId or ACI properties?

In case you do not know what Volatile Transactions (aka In-Memory Transactions) are, they are transactions that do not persist to a durable store such as a hard disk (ouch! we have multiple definitions of durable to content with ). They are transactions that are done completely in memory and do not incur the I/O cost of writing to a hard disk a Transaction log or the actual known data/state.

What is interesting about Volatile transactions is that they are sometimes perceived as not being Transactional, because they are viewed as not meeting the ACID properties, especially the "D" property. I suspect the main reason for this view is because there are no Transaction logs and/or no data stored to hard disk.

So when you look at a typical definition of the ACID properties (like what I have listed below), some of the reasons why this view maybe held become apparent:

(NB. this is an amalgamation/synopsis of many definitions I have seen)

A - Atomicity - Transactions are atomic (all or nothing)

C - Consistency - The transaction is a correct transformation of state. Consistency constraints that are defined on the underlying data servers are preserved by a transaction.

I - Isolation - Each transaction should appear to execute independently of other transactions that may be executing concurrently in the same environment.

D - Durability - Once a transaction commits, it’s updates survive even, if the system goes down

ok, so a Volatile Transaction meets the ACI of the ACID properties, but not the D as defined above. But is this ("Once a transaction commits, it’s updates survive even, if the system goes down") a true reflection of what Durability means? Many similar variants of this definition gets used on a frequent based and they bring specifics to the definiton that are not about the failure of meeting the ACI properties or making the "Commited" value available/public but focus on the failure of media or a system. In my opinion the failure of media or a system is not an aspect of the paradigm or indeed part of the ACID properties, but an aspect of how the paradigm can be implemented and/or a requirement of the longevity of the state being persisted/determined. It is perhaps the fact that the best known implementation of the data server feature of the transactional paradigm is a database that has led us to shape the ACID properties to the specifics of databases. But perhaps the Transactional paradigm has more to offer than the correctness of data/state transformations on a database. The transaction paradigm has a core focus on simpilifing how we can achieve the correctness of data/state transformations where we may have to deal with concurrency management and recovery control and this can be applied to any transformation of state.

Perhaps a different way to look at the durability of ACID is where the definition of ACID as an acronym came from and how some of the leading experts in the industry define them. As far as I know the ACID acronym was first coined by Haerder and Reuter (1983). The definition I like to use is that by Gray and Reuter (1993). It is the following:

A - Atomicity - A transaction's changes to state are atomic: either all happens or none happen. These changes include database changes, messages, and all actions on transducers.

C - Consistency - A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.

I - Isolation - Even though transactions execute concurrently, it appears to each transaction, T, that others executed either before T or after T, but not both

D - Durability - Once a transaction completes successfully (commits), its changes to the state survive failures.

When you read this definition of Durability (and the ACID properties overall), it in my option explains the feature richness of transactions and how it can be applied to the persistence of the transformation of state and also how it applies to the other properties such as A, C and I. The state survives failures by the data server ensuring that when the transaction commits a new durable state is persisted/stable/available/public and if something goes wrong (such as not be able to ensure Consistency) that the data server returns to the previous known state. In essence, this is a contract that guarantees the persistence and stability of the state and that the outcome of a transaction is known/public and usable in subsequent transactions, as a known/correct state. A good definition I have seen is that once a transaction is committed, it cannot be abrogated.

With Durability being about the persistence, stability and making public of “commited”/known state as we transform from one known/correct state to another, it allows us to leverage the transaction paradigm in many scenarios. For example when using Volatile Transactions, we are leveraging data servers that store data on Volatile media, such as RAM and providing the transaction paradigm in-memory. With the common misunderstanding that Transactions are exclusively for databases, the question arises about the “D” property.

For me the Durability aspect of a transaction is present in a Volatile transaction. The question is whether its “D” or “d”. Since most transactions are based on the X/Open Transaction processing model, the requirement for log managers or lock managers in resource managers (data servers) are not central or core to implementing the transactional paradigm at a base level. In relation to the usage of Volatile media for Transactions? in my opinion the requirement of the media used by the data server is that it is able to present a stable/persistent/public state once "Commit" has occured. So I believe that Volatile Transactions meet all of the ACID properties and that its ACID with a "D"

phew! long post.

I guess the crux of the issue is the 2 uses of "durable" when talking about Transactions. One is the "D" in the ACID properties and the other is the property of the data/state/media being used (and how it is stored). The "D" in the ACID properties is more about making a "commited" value available and the other is about an implementation requirement of how long (and/or resilient) a known/committed state must be.

 

A new section of the .NET Framework Developer Center went live today, it focuses on 64-bit .NET Framework programming.

Over to Frank Redmond for the details:

<extract>

Check out the MSDN .NET Framework Developer Center’s new 64-bit .NET Framework programming section! The new 64-bit .NET Framework programming section includes: development articles, tools and community resources as well as 2 step-by-step Hands-On Lab (HOL) samples that will get you up to speed quickly on 64-bit .NET Framework programming. HOL501 addresses the most common managed code migration scenarios: migrating managed code with no native dependencies, migrating managed code w/a dependency on a native DLL, migrating managed code w/a dependency on a native DLL that requires unsafe code and migrating managed code w/a dependency on a native COM component. HOL503 addresses C++ migration issues such as data type changes to the Win32 API and floating-point differences as well as investigating memory performance considerations. The new 64-bit .NET Framework programming section also includes a step-by-step guide on Visual Studio 2005 remote debugging. Check out the new 64-bit .NET Framework programming section on the MSDN .NET Framework Developer Center and let me know what you think!

</extract>

 

At http://www.microsoft.com/seminar/events/series/msdn64bitwin.mspx you will find a series of Webcasts that focus on 64bit computing on Windows.

Tune in to this webcast series and learn of the advantages that 64-bit computing brings:

• Run existing 32-bit code without modification on 64-bit Windows.
• Write native 64-bit code (managed and unmanaged)
• Learn about the next generation of development tools.
• Find out about 64-bit processor architectures.
  

Pascal and the Irish Developers Alliance members have been busy. The site is live and you can find forums and blogs for Irish developers. Nice one folks!

Well lots of folks gave feedback that they would like to see C# support for Edit and Continue in Whidbey, and its on the way. See Soma's blog for the announcement. Congrats to all involved.

Yesterday, the Application Compatibility Testing and Mitigation Guide for Windows XP Service Pack 2 was published.

This guide considers potential application compatibility issues that may arise after a Service Pack 2 deployment. The guide provides mitigation procedures that can be followed to overcome compatibility issues. Since the mitigation procedures relax the default security configuration, the guide in no way recommends that they should be followed, but if there is no other way of overcoming compatibility issues, they can be applied in the short term.

The Guide also includes a download of example scripts. The scripts demonstrate how to reconfigure a Service Pack 2 computer to overcome compatibility issues. The scripts are designed as functional samples and will require modification for use in a production environment.

I've only flicked though it, but I am very impressed with the level of detail of what I've seen todate.

 

Server Performance Advisor can be found here. It was released a few days ago.

<Extract>

Overview

Service Performance Advisor is a server performance diagnostic tool developed to diagnose root causes of performance problems in a Microsoft® Windows Server™ 2003 operating system, particularly performance problems for Internet Information Services (IIS) 6.0 and the Active Directory® directory service. Server Performance Advisor measures the performance and use of resources by your computer to report on the parts that are stressed under workload.

Other server roles include system overview (hot files, hot TCP clients, top CPU consumed), print spooler, context switch data and preliminary File Server trace data.

</Extract>

 

Haven't used it yet, put looking the the details in the overview, it looks like it will be very useful. I'll post an update when I have had a chance to use it in anger.

Orginally found a posting on it on denes 's blog.