Server scalability on the internet has traditionally been handled by using multiple computers on a local network. While this has worked well for simple web servers, or more generally when clients don't influence eachother, it becomes a problem when they do.

In more complex distributed designs, where there is a significant amount of data exchanged between the nodes on the local network, a new set of rules comes into play. Atomicity, Consistency, Isolation and Durability (ACID) must be given up in order to truly take advantage of going distributed. But while it is clear that the old rules no longer apply, what could replace them is still nebulous. Distributed programming has remained extremely difficult.


Before using networks of small computers to solve complicated problems came into fashion, there were mainframe computers: massively parallel machines that could do many things at the same time. Ordinary present-day computers resemble those old giants in one significant way: many of them have multiple CPUs, or CPU cores.

Hydra takes a step back from distributed systems, and merely tries to make full use of all CPUs on a single computer, as if it were a mainframe. Hydra retains the principles of ACID, using transactional semantics to simulate a single-threaded system. To the programmer, there are no threads, no locks, and no deadlocks.

How it works

Programming in Hydra is event-driven. Tasks, which are all of finite (and short) duration, are either started by input from a remote client, or are scheduled by a preceding task. Tasks work on a copy of all the data they access, and finish by attmpting to commit their changes to the originals. If no other task has committed changes to the same data in the meanwhile, they succeed; if not, the changes are discarded and the task is rolled back to start over.

As a way to visualize this, imagine the many heads of a Hydra at work. Each head handles one task at a time. Each head works on its own, ignoring the other heads; but sometimes a conflict occurs between them. In such a case, the head that completed its task first is victorious, and the other head is cut off. The chopped-off head then grows back, and begins anew.

Persistence and more

Hydra offers the programmer a database, and an object-oriented programming language called LPC running on a virtual machine. However, LPC programs do not interact with the database, they are part of the database, alongside the data they work on. Rather than traditional records, rows and tables, the database offers persistence: the full state of the system is preserved across reboots.

As objects can be recompiled in place while remaining functional, complex database upgrades can be performed without taking the system down, and even without missing a beat. When a reboot is necessary, for example to upgrade Hydra itself, the system can be back up again in seconds.

Hydra also offers rollbacks in a different context: a function in LPC can be made atomic, so that if an error should occur inside it, all the changes made by that function are rolled back. This has proven to be invaluable for preserving consistency in a persistent system.


Hydra is the successor of, and compatible with DGD. DGD began its life as a MUD server engine, and is still used in that fashion, for example by Skotos. DGD became open source in February 2010. Hydra and DGD are fully compatible; the only difference is that Hydra is faster on multi-processor machines.

Executables for Hydra are frequently made available here. These are fully functional, but are limited to at most 64K objects and 255 connected users. Unrestricted binaries are available under a commercial license.


You can contact me at felix@dworkin.nl (whitelist registration required).

There is also a forum for discussing Hydra and DGD.