Over at his blog, Patrick Logan asks why people find transactional memory to be shiny? I think it's the usual reason: it looks to them like a silver bullet.
I know Patrick worked at GemStone with their transactional products, and I spent a number of years writing an app dev system on top of the GemStone transactional object database as well as writing a custom transaction manager for a port of the app dev system to Java. So we're both aware of the problems with transactional memory and the complexity it can entail.
But if you haven't been there and done that transactional memory is seductive; it promises that you won't have to change much to enjoy the benefits of multi-CPU systems. And like the SOAP stack, it initially seems to deliver on the promises. But as the number of processes accessing the data increases, as transactions get longer, and as the amount of data inside the transactions increases they'll find that the the costs in quickly outweigh the benefits.
I'm expecting that the industry will detour into the transactional memory dead end for awhile, just like they did with the SOAP stack and by the time they come back they'll be ready to make the harder changes necessary to do it with an Actors/Erlang type approach.
