Old Wine, New Bottle: Transactions and Garbage Collection in the Cloud

Last night, Gil Tene, CTO of Azul Systems, and Tom Henn, CEO of CloudTran, spoke at the SDForum’s Cloud Computing and Virtualization SIG, addressing old themes in computer science that take on new meaning in the cloud.

Tene pointed out that the memory available on servers has increased a hundredfold for each of the last several decades. Commodity servers now ship with hundreds of GB. Yet application developers do not take advantage of this plentiful memory out of fear of garbage collection: the garbage collectors available Java Virtual Machines (JVMs) require delays measured in minutes when memory usage exceeds several GBs.

The limitations of garbage collection—a function needed to compact memory used by an application and free memory no longer needed—become ever more acute in multi-tenant cloud environments, where applications should expand to meet capacity and then release that memory for other applications when the load declines.

Azul Systems, according to Tene, has tacked the problem by implementing the only commercial JVM with concurrent garbage collection, meaning that it compacts and releases memory as the application runs without the need for delays. Azul System’s JVM, the Zing Virtual Appliance, runs directly against hypervisors in a virtual environment.

Another company to tackle an old problem made new in the cloud, CloudTran takes on the problem of transactions. Public and private clouds can spin up additional web and application servers as needed to meet demand, but the database becomes a bottleneck. Scaling out databases has meant giving up transactions—the ability to read and write across tables in a manner that is atomic, isolated, durable, and leaves the system in consistent state. Transactions have long been critical for business applications, but making transactions scale across multiple databases has proven difficult.

The tradition approach, distributed transaction coordination, involves middleware making transaction requests across multiple databases, waiting for each to respond, and then issuing a commit or abort command back to each database as appropriate. This distributed transaction coordinator approach builds on the transactional capabilities of relational databases but it cannot scale to cloud proportions.

CloudTran claims to have solved this problem by building a Virtual Transaction Manager that operates independent of specific databases. The transaction manager pulls the needed data into memory, performs the transaction, and then makes the needed writes across the databases. With this technology,  OLTP (online transaction processing) makes way for CloudTP.