fib(0) = 1
fib(1) = 1
fib(n) = fib(n-1) + fib(n-2)

In Scala it looks like this.

def fib(n: BigInt): BigInt = if (n < 2) 1 else fib(n-2) + fib(n-1)

We assume of course that input n is always a positive integer number. From a mathematical perspective this is a beautiful implementation, concise and elegant. However, something is very wrong with this implementation. Can you spot it?

Exactly: it’s inefficient. Just think about it for a while, without formal proof we can intuitively guess the complexity of this algorithm. It’s equal to the very number it computes!

O(fib(n)) = fib(n)

Simply measure some executions and see for yourself.

import java.lang.System._

def main(args: Array[String]): Unit =
  for (n <- 1 to 38) {
    val t1 = currentTimeMillis
    fib(n)
    val t2 = currentTimeMillis
    println(n, t2 - t1)
  }

Lovely to see how the execution times follow one another in true fibonacci style.

The problem is that intermediate values are computed over and over again in every recursive branch of the algorithm. It would be nice if for a given number x, we could cache fib(x) and re-use that pre-calculated result when we need it calculating y where y > x. This technique is called function memoization.

Function memoization boils down to a higher-order function that takes the original function as input, and returns another function with the caching mechanism built in.

def memoize[A, B](f: A => B) = new (A => B) {

  val cache = scala.collection.mutable.Map[A, B]()

  def apply(x: A): B = cache.getOrElseUpdate(x, f(x))

}

The Scala implementation is remarkably simple. We accept a generic function f, and return an anonymous function with the same generic types. The cache is a simple HashMap. The function application method consults the cache and returns it if present, else it computes the desired result, stores it in the cache and returns that result. All this is cleverly implemented by the mutable.Map getOrElseUpdate method:

def getOrElseUpdate(key: A, op: => B): B

Note that the second parameter is lazy, the passed function is only evaluated when necessary. In Java this is very awkward to implement because parameter passing always has call-by-value semantics.

So, are we done? Can we speed up our fibonacci function by memoizing it? Let’s find out…

def main(args: Array[String]): Unit = {
  val fib_memoized = memoize(fib)

  val t1 = currentTimeMillis
  val r  = fib_memoized(38)
  val t2 = currentTimeMillis

  println("result %s calculated in %s milliseconds".format(r, t2-t1))
}

result 39088169 calculated in 8480 milliseconds

&%#@!! Curses and profanity! It turns out the cache is only consulted once. Why is that? What is wrong? Is it because there is something special about our fibonacci implementation?

Ah, yes…

It’s recursive.

Our problem turns out to be more tricky than initially expected. We somehow need to weave the memoization down the recursive calls of the function. Let’s call a knowledgeable gentleman on stage to help us out here. Please welcome… Haskell Curry!

Haskell Curry, a pioneer in the field of combinatory logic, discovered a fascinating function called the Y combinator. If you’ve got a red pill handy and want to know more about it, the rabbit hole is this way. Pretty mind blowing stuff!

In a nutshell, what is it and how can we use it? The Y combinator is a higher-order function that takes a non-recursive function and returns a version of that function that is recursive.

Hey! Wait a minute! But our fibonacci function is recursive, so we can’t feed it into the Y combinator, right?

Correct. The trick goes as follows: if we could somehow turn our fibonacci function in a non-recursive function, we could use the Y combinator to transform it into a recursive one with memoization built in, we’re done!

Let’s begin with the first step. We need to pull the recursion out of our beloved fibonacci function. This means eliminating the two recursive calls to itself.

def fib(n: BigInt): BigInt = if (n < 2) 1 else fib(n-2) + fib(n-1)

We substitute the recursive call by a new function g: BigInt => BigInt, that we pass to the fib function as an extra argument.

def fib(g: BigInt => BigInt)(n: BigInt): BigInt = if (n < 2) 1 else g(n-2) + g(n-1)

We redefine the memoize function as follows:

def memoize[A, B](f: (A => B) => A => B): (A => B) = {

  val cache = scala.collection.mutable.Map[A, B]()

  def y(f: (A => B) => A => B): (A => B) =
    a => cache.getOrElseUpdate(a, f(y(f)(_))(a))

  y(f)

}

The memoize function defines the nested Y combinator function y, which implements the caching strategy. The result of the memoization is again a function equal to the Y combinator applied to our non-recursive function f.

Let’s find out if it does work faster now!

def main(args: Array[String]): Unit = {
  val fib_memoized = memoize(fib)

  val t1 = currentTimeMillis
  val r  = fib_memoized(1000)
  val t2 = currentTimeMillis

  println("result %s calculated in %s milliseconds".format(r, t2-t1))
}

result
7033036771142281582183525487718354977018126983635873274260490508715453711819693357974
2249494562611733487750449241765991088186363265450223647106012053374121273867339111198
139373125598767690091902245245323403501 calculated in 73 milliseconds

Err… nope, mr. Spock. Your codes aren’t perfect. Depending on your JVM configuration, this implementation will sooner or later result in a stack overflow. This problem plagues every recursive function that is not tail recursive and therefore cannot be subject to tail call optimization.

In a real-world situation, an imperative implementation with a loop instead of recursion (or almost-recursion with the Y combinator) is obviously the better choice.

Nonetheless, functional programming is powerful and a lot of fun!

Hold on, brightness is not exactly the correct term here, f.lux allows you to adjust the screen’s color temperature, not just its intensity. Researchers believe the blueish light of a computer screen tricks your brain into thinking it is still day time. Shifting the color temperature to a more reddish hue is not only softer on your eyes, it can actually improve your sleep quality. This is especially helpful for nocturnal people like myself who often use the computer before going to sleep. And it’s quite cosy!

In fact it reminds of how much I hate these energy-saving light bulbs, especially the cheaper ones you can buy at Ikea. The old-fashioned incandescent light bulbs are banned from stores in Belgium for ecological reasons (not taking into account nasty chemicals like mercury involved in making energy-saving fluorescent lamps). I liked those so much better. Still have some spare ones, hee hee :p

As an experiment, install f.lux and do something useful like working on your latest code project for let’s say 10 minutes with the color temperature set to ‘halogen’ (3400K). Then switch it back to the default daylight setting (6500K). Holy toledo Batman, my eyes! Aaarghl!

I’ve started using f.lux during my daytime work as well, just slightly adjusting the temperature from the default 6500K to a slightly more mellow 5800K. Much nicer.

Highly recommended, check it out.

Couldn’t resist sharing this little Java vs. Clojure episode. Consider following interview question (stolen from a blog post):

given a string such as “AABAB”, return the string with all consecutive duplicate letters removed, ergo: “ABAB”

I’m a professional Java guy with a few years of experience, this should be a piece of cake, right? Following code is what I vomited onto my IDE in about 5 minutes. It’s not optimal, nor very beautiful, but it works. Consider it a brain dump, I’d polish it up in real project.

public class RemoveDuplicatesTest {

    @Test
    public void test() {
	assertEquals("", removeDuplicates(""));
	assertEquals("A", removeDuplicates("A"));
	assertEquals("AB", removeDuplicates("ABBBBBBBB"));
	assertEquals("ABAB", removeDuplicates("AAAABBAAB"));
    }

    private String removeDuplicates(String string) {
	if (string == null) {
    	    throw new IllegalArgumentException();
	}

	if (string.length() == 0) {
	    return "";
	}

	final char[] chars = string.toCharArray();

	char current = chars[0];

	final List acc = new ArrayList();

	for (char c : chars) {
	    if (c != current) {
	        acc.add(current);

	 	current = c;
            }
 	}

	if (acc.isEmpty() || acc.get(acc.size() - 1) != current) {
	    acc.add(current);
	}

	final StringBuilder result = new StringBuilder();

	for (Character c : acc) {
	    result.append(c);
	}

	return result.toString();
    }

}

Now, I’ve been reading up on Clojure since last week, so I gave it go as well. About half an hour of messing around in the La Clojure REPL, not too bad for a Clojure newbie. Lost some time looking up how to turn a vector into a String.

(defn removeDuplicates [arg]
  (loop [chars arg, acc []]
    (if (empty? chars) acc
      (recur (rest chars) (if (= (first chars) (last acc)) acc (conj acc (first chars)))))))

(defn to-string [s]
  (apply str s))

(= "AB" (to-string (removeDuplicates "AAABBB")))

I’m not entirely sure this qualifies as idiomatic Clojure but it looks pretty tight, would you agree? Also note that the assignment kind of pushed me to think in terms of removing duplicates from a String. The Clojure version is more generic out of the box and removes duplicates from a seq instead, but works for a String as well because a String is also a seq of characters.

I think it’s rather scary that my supposedly well-developed Java brain produces that ugly pile of code, and my embryonical Clojure brain spits out a solution that just beats the crap out the Java implementation. I’m a strong believer in the Sapir-Whorf hypothesis in the context of programming languages, this example adds yet more proof to it.

The principle of linguistic relativity holds that the structure of a language affects the ways in which its speakers are able to conceptualize their world[..]

Clojure is awesome.

As I mentioned in my previous post on DCI, the key technique I use to glue the different parts of the code together is the Cake Pattern, a technique for doing dependency injection in Scala. Although it is suitable for that, I think it is capable of more. Having a Java background, I regard dependency injection as a way to piece together object graphs, where the different components are objects instances. The result of this is usually a static object graph where the different objects are some sort of stateless containers for logically related methods. I am maybe stereotyping here, but this is what a lot of Spring applications look like. The Cake Pattern is actually a lot more powerful than traditional dependency injection. Instead of piecing together object graphs, you can actually weld a pile of traits together into very precisely synthesized objects. Or in other words, it is not an object graph that is built from object instances, it is a single object that is built from traits. When learning about that, it struck me that the Cake Pattern could potentially be a very suitable technique for doing DCI in scala. DCI is all about putting together exactly the needed functionality into a small object graph, launching an interaction, and then letting the created objects be garbage collected again. I think DCI is an excellent theory for guiding developers in deciding which components to create. The Cake Pattern can then be used to piece those components together into a working software system.

A scenario

Before diving into the code, let’s briefly have a look at the scenario we’re going to implement. Image being the user of a banking application. The system has a button which allows you to pay all your unpaid bills with only one click. However, the entire transaction fails if you don’t have enough money in your bank account to pay them all. We’ll translate this to DCI artifacts. The user of the system plays a role in our case. He is a person that has bills to pay, which makes him a debtor. Or in other words, a user is represented by the Person class, and Debtor is the role that is mixed in into the Person object, in the PayBillsContext. Let’s clarify with a not-so-UML-compliant graphical representation.

Notice the blue balloons, these are the nested contexts I mentioned earlier. It is the methodful role implementation TransactionalDebtor of the methodless role Debtor that instantiates and executes TransferMoneyContext objects. Conceptually this is easy to grasp, but don’t forget that the TransferMoneyContext object is a configured “business” component that is capable of working with a transactional resource like a database. So how can the methodful role instantiate such an object? Doesn’t this remind of the anemic domain model debate? Or the question whether it is a good idea to inject business objects into domain entities? Now we’re cooking. Enter the almighty Cake Pattern.

Salt, pepper, Scala… check!

The Cake Pattern is something very particular of Scala. Based on Martin Odersky and Matthias Zenger’s paper called Scalable Component Abstractions, it was later baptised under its common name by Jon Pretty in a discussion thread. Quoting Jon:

(…) beyond my appreciation of cake, [a] cake is made of a number of layers (separated by jam), and can be sliced. The layers represent the different levels of inner class nesting. It is conceivable that you would reach the bottom layer by working your way down from the top.

It is a very weird pattern, I’ll happily admit that. The best way to get your head around it is to code up something yourself. It honestly took me quite a while before my penny really dropped. Anyhow, the beauty of this pattern is that because of its nested traits, the line between entities and business components becomes very blurred. An entity instantiated in a Cake Pattern-y business component al of a sudden has access to the dependencies of that business component, defined by self-type annotations. It becomes even weirder when, in a certain business component, you implicitly convert an existing entity into a role, where the implicit conversion is defined in a trait on which that business component depends, where that trait has dependencies of its own, also defined by self-type annotations. The modest domain entity all of a sudden gains business component superpowers! Yikes! Everybody still with me? Let me illustrate with some code, starting with the Debtor role and the PayBillsContext.

trait Debtor {
  def payBills
}

trait Context {
  def execute
}

trait PayBillsContextFactory {
  this: DebtorProvider =>

  class PayBillsContext(val person: Person) extends Context {
    def execute = person.payBills  // implicit conversion from Person to Debtor
  }

}

The Debtor trait, a methodless role, is pretty straightforward, it has only one method. (Rereading this sentence it struck me how contradictory that sounds, a “methodless role with one method”. With methodless roles DCI refers to methods without implementations, just to clarify) The PayBillsContext class is also very simple, it has a Person variable and an execute method. But look, in that execute method, we call the payBills method on a Person instance! Somehow that Person must have secretly been turned into a Debtor, otherwise this wouldn’t compile. How can this be?

I know kung fu

Notice that the PayBillsContext class is an inner class defined in an outer trait PayBillsContextFactory. The outer trait is pretty empty, apart from its self-type annotation DebtorProvider.

trait DebtorProvider {
  implicit def asDebtor(person: Person): Debtor
}

An abstract implicit conversion method. How does this work? When the Scala compiler sees some method being called on something that doesn’t have that method, it looks for implicit conversions in scope that could solve this conflict. In this case, the compiler finds that abstract implicit conversion method in the self-type of the PayBillsContextFactory trait, namely the DebtorProvider trait. This is a compatible conversion, so the compiler is happy and doesn’t complain. This is wicked! In the context of paying bills, the Person object is provided with all the intelligence he needs in his role as Debtor. Doesn’t that remind you of something?

Indeed Mr. Anderson, you know kung fu. Let’s have a look at what kind of kung-fu you know.

trait TransactionalDebtorProvider extends DebtorProvider {
  this: Transactional with PayBillsQueries with TransferMoneyContextFactory =>

  implicit def asDebtor(person: Person): Debtor = new TransactionalDebtor(person)

  class TransactionalDebtor(self: Person) extends Debtor {

    def payBills = inTransaction {
      findUnpaidBills(self.id) foreach {case (bill, creditor) =>
        new TransferMoneyContext(self.accountId, creditor.accountId, bill.amount).execute
        markAsPaid(bill.id)
      }
    }

  }

}

In the TransactionalDebtorProvider trait, the abstract implicit conversion method is implemented. It returns an instance of the TransactionalDebtor class, which wraps a Person instance and implements the Debtor trait. You all know what this is called right? It’s an adapter. Actually I would have liked to implement the TransactionalDebtor as a trait, with Person as a self-type annotation, but I haven’t found a way to glue such a trait onto an existing object. I don’t think it is possible at all in Scala (if it is, please tell me how). You can only mix in such a trait at object instantiation, that’s as close to dynamic traits as you get, i’m afraid. Still, the implementation is quite clean. The fact that the DCI methodful role is implemented as a class instead of a trait is only a minor aesthetical flaw.

Let’s zoom in on what is going on in the payBills implementation. In a transaction, a query is launched to retrieve the Person’s unpaid Bills, and each bill is paid by executing a TransferMoneyContext. Lastly, the Bill is marked as paid. The implicit conversion from Person to Debtor provides that Person with this functionality. The TransactionalDebtor is able to launch transactions, execute queries and create TransferMoneyContext instances because its outer trait, the TransactionalDebtorProvider, has the necessary dependencies, defined as self-types: Transactional, PayBillsQueries and TransferMoneyContextFactory. Remember me saying that the Cake Pattern somehow blurs the line between domain entities and business components? No need for implementing hooks in an ORM framework so that it interacts with a dependency injection container in order to inject business components into entities. (For more information about the TransferMoneyContext, see my previous post)

In summary, every outer trait sits on top of its self-types, which in turn sit on top of their self-types. The only thing we still need to do is do the actual welding together of all the traits.

trait LayerCake
  extends PayBillsContextFactory
     with TransactionalDebtorProvider
     with PayBillsQueriesSqueryl
     with TransferMoneyContextFactory
     with TransactionalMoneySourceProvider
     with TransactionalMoneySinkProvider
     with UpdatableAccountAspect
     with CalculatedBalanceAspect
     with MoneyTransferQueriesSqueryl
     with TransactionalWithSqueryl
     with Tables
     with MyDataSource

What does this look like to you? It’s a layer cake! A stack of traits, summarized in a trait, which can then be mixed into other traits or objects.

Conclusion

Using the Cake Pattern, working with nested DCI Contexts is absolutely trivial. As is injection of all kinds of logic that is untypical of domain entities. Injecting roles into existing objects can be done rather elegantly with implicit conversions. The beauty of it all is that I don’t need any frameworks to do all this. It’s just Scala.

That’s it! I hope that I’ve somehow been able to convey the train of thought that led to this implementation. Don’t be shy and comment away!

The code is available on Google Code.

It compiles with the final Scala 2.8 release and has a few dependencies:

• squeryl_2.8.0-0.9.4beta8.jar – an impressive Scala DSL for SQL queries, recommended!
• cglib-2.2.jar
• asm-3.2.jar
• c3p0-0.9.1.2.jar
• mysql-connector-java-5.1.10

Peace.

For those who are not familiar with the Cake Pattern, it might be a bit confusing. However, there is an excellent post on Jonas Bonér’s blog that explains it in detail. It could be useful to read up on that first before continuing.

The use case I will try to implement in this exercise is a simple one. Imagine a user of a banking system wishes to transfer $20 from her account to that of a particular creditor. In DCI lingo, this means instantiating a context object and calling an ‘execute’ method.

object TestApp extends Application with Registry {
  val sourceAccountId = 1
  val destinationAccountId = 2
  val amount = 20.0
  val context = createTransferMoneyContext(sourceAccountId, destinationAccountId, amount)

  context.execute
}

The TestApp object has access to the createTransferMoneyContext method because it mixes in the Registry trait. This trait is responsible for actually glueing together all necessary components. The registry could be compared to a Spring application context or a Guice module. The difference is that instead of piecing together an object graph, we weld all traits together in a single object, in this case, the TestApp. More on this later. Let’s continue with the TransferMoneyContext class and how it is created.

trait TransferMoneyContextFactory {
  this: TransactionalMoneySourceProvider with MoneySinkProvider =>

  def createTransferMoneyContext(sourceAccountId: Long, destinationAccountId: Long, amount: Double) =
    new TransferMoneyContext(sourceAccountId, destinationAccountId, amount)

  class TransferMoneyContext(val sourceAccountId: Long, val destinationAccountId: Long, val amount: Double) {
    def execute = {
      val source = getTransactionalMoneySource(sourceAccountId)
      val destination = getMoneySink(destinationAccountId)
      source.transferMoney(amount, destination)
    }
  }

}

Ok, those not familiar with the Cake Pattern might scratch their heads now. I know I did when I first saw this strange nested trait business. The inner class is the DCI context class. It’s very simple, having only an execute method. The context class does nothing but bringing the actors to the stage (the money source and the money sink) and triggering the interaction. The context class receives its capabilities from the outer trait and the self-type annotations of the outer trait. In the Cake Pattern, self-types are used to define dependencies, in this case a provider for the money source and a provider of the money sink.

The MoneySource and MoneySink traits are the so-called methodless roles as per the DCI paradigm. Very simple, they only expose the methods necessary for the interaction.

trait MoneySink {
  def deposit(amount: Double)
  def updateLog(msg: String, amount: Double)
}

trait MoneySource {
  def transferMoney(amount: Double, moneySink: MoneySink)
}

I factored out the logic for bringing instances of these traits in what I call respectively the MoneySinkProvider and the TransactionalMoneySourceProvider. Let’s take a look at the MoneySinkProvider first.

trait MoneySinkProvider {
  this: UpdatableAccountAspect =>

  def getMoneySink(accountId: Long) = new Account(accountId) with UpdatableAccount with MoneySink

}

Aha, here we first encounter the Account class. Those who have seen Jim Coplien’s presentations know that in the financial world, there is no such thing as an Account object. An account is a computation, not a record with a balance stored in a database (this is actually a good example of Event Sourcing). But here we do see an Account object, what the devil is going on?

What I did is create an illusion of an Account object. It looks like a JPA-style Account entity that has methods to manipulate the balance field, but all we have is just an abstract class.

abstract class Account(val id: Long) extends Identified {
  def deposit(amount: Double)
  def withdraw(amount: Double)
  def updateLog(msg: String, amount: Double) = println("Account " + id + " " + msg + " " + amount)
}

In the financial world, updating the balance of an account boils down to persisting a record with the transferred amount of money. Something that looks like the following class.

class MoneyTransfer(val accountId: Long, val amount: Double)
  extends KeyedEntity[Long] with Identified {
  val id: Long = 0
}

object Deposit {
  def apply(accountId: Long, amount: Double) = new MoneyTransfer(accountId, amount)
}

object Withdrawal {
  def apply(accountId: Long, amount: Double) = new MoneyTransfer(accountId, -amount)
}

It has a number that represents the account number and the transferred amount (and a technical id). The two other object provide factory methods, nothing more than programming esthetics really. So what we want to do in an Account instance is persist another of those MoneyTransfer records behind the scenes of the deposit and withdraw methods. That’s where the UpdatableAccountAspect comes in. Note that the MoneySinkProvider trait has a self-type annotation specifying that it depends on the UpdatableAccountAspect.

trait UpdatableAccountAspect {
  this: MoneyTransferQueries =>

  trait UpdatableAccount {
    this: Account =>

    def deposit(amount: Double) = persist(Deposit(id, amount))
    def withdraw(amount: Double) = persist(Withdrawal(id, amount))
  }

}

The inner trait encapsulates the capabilities that can be mixed into an Account object, giving that object the power to persist a MoneyTransfer instance in the case of a deposit or withdrawal. Summarized, when the MoneySinkProvider creates an Account instance, it mixes in the capability for updating the balance, and wraps it up under the guise of a MoneySink. As you see, there is no methodful role for a MoneySink, because there is no need for it. There is no interaction code for a MoneySink. Note that this object has no idea whatsoever of what its balance actually is! It does not have to know. It does not play a role that has to know. I’m a money sink, I receive money! Nothing more.

The MoneySource provider is a different animal.

trait TransactionalMoneySourceProvider {
  this: Transactional with UpdatableAccountAspect with CalculatedBalanceAspect =>

  def getTransactionalMoneySource(accountId: Long) =
    new Account(accountId)
      with UpdatableAccount
      with CalculatedBalance
      with TransactionalMoneySource 

  class InsufficientFundsException extends RuntimeException

  trait TransactionalMoneySource extends MoneySource {
    this: Account with HasBalance =>

    def transferMoney(amount: Double, recipient: MoneySink) = {
      transactionally {
        if (amount > balance) throw new InsufficientFundsException
        withdraw(amount)
        recipient.deposit(amount)
        updateLog("balance decreased with $", amount)
        recipient.updateLog("balance increased with $", amount)
      }
    }
  }

}

The TransactionalMoneySource is the methodful role corresponding to the MoneySource methodless role. This is where the interaction logic resides. Within the boundaries of a transaction, the MoneySource checks whether it has sufficient funds, decreases its balance, increases the balance of the recipient and updates the logs of both Accounts. Aha, so a MoneySource must be aware of its balance! How does it know that? This capability is mixed in with the CalculatedBalanceAspect.

trait CalculatedBalanceAspect {
  this: MoneyTransferQueries =>

  trait CalculatedBalance extends HasBalance {
    this: Account =>

    lazy val balance = calculateBalance(id)
  }

}

Again the familiar nested trait structure. The CalculatedBalance trait is able to compute the current balance of the account by executing a query (in this case the computation is done in the database). Summarized, the TransactionalMoneySourceProvider creates an object that pretends it is an account, is able to calculate and update its balance and knows the necessary steps to perform a money transfer. Nice. So these are the components relevant to DCI. The other components are more of a technical nature.

Lastly, let’s revisit the Registry trait.

trait Registry
  extends TransferMoneyContextFactory
  with TransactionalMoneySourceProvider
  with MoneySinkProvider
  with UpdatableAccountAspect
  with CalculatedBalanceAspect
  with MoneyTransferQueries
  with Database
  with Transactional
  with TransactionManagerComponent
  with SessionFactory
  with DataSourceComponent {

  val dataSource = {
    val ds = new AtomikosNonXADataSourceBean

    ds.setUniqueResourceName("MyDatabase")
    ds.setUser("root")
    ds.setPassword("admin")
    ds.setUrl("jdbc:mysql://localhost:3306/TMC")
    ds.setDriverClassName("com.mysql.jdbc.Driver")
    ds.setPoolSize(1)

    ds
  }

  val userTransaction = new UserTransactionImp

}

This is the trait that welds everything together. It’s a concatenation of the outer traits we saw earlier. It is also the place where the actual DataSource and UserTransaction objects are instantiated. Mix in this trait in a client object and it is able to request and execute a new TransferMoneyContext instance.

That’s about it! Hope it all makes sense somehow.

The code is available on Google Code.

The dependencies:

• squeryl_2.8.0.Beta1-RC8-0.9.2.jar – an impressive Scala DSL for SQL queries, recommended!
• cglib-2.2.jar
• asm-3.2.jar
• mysql-connector-java-5.1.10
• Atomikos transactions-essentials-all.jar
• jta.jar – the Java Transaction Api

You will need Scala 2.8.1 to compile it, SQueryl doesn’t work with Scala 2.7.x. There’s a schema generation script for creating the database. If you create the schema by hand, make sure to use the InnoDB database engine. The default one, MyIsam, does not support transactions (had me banging my head against the wall for a few hours, puzzled as to why my transactions wouldn’t work).

Feedback and suggestions are most welcome, don’t hesitate to drop me a line!