New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on May 01, 2007
Microsoft has announced that they are building an extension to the Common Language Runtime called the Dynamic Language Runtime (DLR). This extension is being designed to enable interoperability between dynamic languages in the same manner that the CLR enabled interoperability between statically typed languages.
Currently the biggest problem with dynamic language interoperability is the lack of a unified object model. Even when running on the same underlying platform like the CLR or JVM, each dynamic language had to independently extend the type system to support modifying classes at runtime. These implementations are inherently incompatible, making it difficult or impossible for languages like IronPython and RubyCLR to share objects.
The Dynamic Language Runtime offers a shared dynamic type system that should eliminate the barriers between Ruby and Python on the CLR platform. In theory, objects can be freely shared between programs written in each language.
In addition to the dynamic type system, the DLR project intends to offer other functionality for making it easier to develop new languages and port existing ones to the CLR. Jim Hugunin's write
The DLR is about giving you the best experience for your language - true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system.
Jim also lists the four dynamic languages that will initially be built on the DLR. Once these are complete and the platform stabilized, Microsoft intends to work with other language developers that wish to target the DLR.
Microsoft has mentioned that VB was going to adopt more dynamic features, but it never before hinted that it would approach the level of Python or Ruby. What this means for the language is still unknown.
It is important to note that the DLR is being released as open source. This is very good news for the Mono team, as Miguel de Icaza explains.
The release for the DLR is done under the terms of the Microsoft Permissive License (MsPL) which is by all means an open source license. This means that we can use and distribute the DLR as part of Mono without having to build it from scratch. A brilliant move by Microsoft.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
SCM best practices for multiple processes, releases & distributed teams
Fair Trade Software Licensing - A Guide to Neo4j Licensing Options
Given that part of MS strategy is to imbue switching costs into any standard that they adopt (see the book "the keystone strategy" for details), I'm not sure if I like the direction this might take ...
I think the switching cost is obvious. Once your Ruby application starts taking advantage of the BCL, or perhaps a Python library, switching back to pure Ruby will be very painful.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
2 comments
Watch Thread Reply