ScalaDBC Mark 1 is now finished. I have added it to the webapp CVS server. It is tested, but not very thoroughly. Sébastien N. will hopefully start testing it in a real-life application as soon as he comes back from vacation. Please, read the extended entry for some comments about why a Mark 2 version will be needed.
This blog has been a little forsaken. But with this heat-weave over Europe, it is the right time to bring it back to life (all right, that isn't a reason). So here is my current status:
ScalaDBC, the generic database library for Scala is more or less working. Well, actually it is working as far as I can tell, but I haven't put it through any serious testing (special cases etc.). There are two things that need to be finished though:
ScalaDALL is the name I am giving to the database library using for-comprehensions and specific optimisations that is the next task after ScalaDBC. I have started some exploratory work for this as I was really getting frustrated with the bugs that where hindering the advance of ScalaDBC. But there isn't anything really working yet.
Otherwise, I also did a little poster that you can find next to my office's door.
I have improved the retry mechanism for my simple transaction library. There are two improvements: Firstly, memory usage is now constant with relation to the number of retries. Second, the time that a thread will wait until it retries is now calculated in a smarter way: the more a thread has retried getting the lock, the more it will wait until it tries again.
The current version of the library is useable, but there are at least two things that I think should be improved if one wants to use it in real applications:
I have obtained the first data from a database through ScalaDBC. Nothing extraordinary yet, but at least, something is working. I will now expand ScalaDBC's capabilities (it is very limited for now) and smooth all edges that are still a bit rough (and there are plenty of them).
The first optimistic transaction library is now working. The results are rather satisfactory, but improvement is still needed. If you read on, some test results are described. This for-comprehension as a monad proved to be something that I had troubles to grasp, especially since all the different parts (for, flatMap, etc) are named as if they were only for the list comprehension. Anyway, it is now working.
I have also started implementing the library for the database access that will be optimised à la SLinks. Of course, it is quite uninteresting by itself without the changes to the compiler to support its optimisation. But there is a start for everything. Plenty of work remaining for this though.
I have been working (with Burak's help) on writing a simple library providing atomic transactions in Scala. To do this, the for comprehension is diverted from its original use to be considered as a monad instead. In practice, here is how an atomic exchange of the value of two variables would look like:
val x = new atomic.Variable[Int]; val y = new atomic.Variable[Int]; val z = new atomic.Variable[Int]; x.value = 1; y.value = 2; (for ( val a <- x.get(); val _ <- z.put(a); val b <- y.get(); val _ <- x.put(b); val c <- z.get(); val d <- y.put(c); ) yield d) run
The problem now is that the for loop as a monad is something that I find very difficult to get an intuition about. I have a very simple version that locks down the entire program when evaluating the atomic bloc, but this is of course hopelessly inefficient. But when I try to improve from this basic version, I am having troubles grasping how things interact around this comprehension/monad, and getting the right intuition on how to do it. Please, read on for a small explanation on the locking mechanisms I intend to add.
