[rucksack-devel] Stability

[Jochen Schmidt]

Am 07.12.2010 um 12:32 schrieb Henrik Hjelte:

> 
> It was some time ago since I experimented with rucksack. The code was very nice, it has a testsuite and I fixed the only error that was detected by the stress-test. So I think it is safe in some sort of way: no failing tests in a decent test-suite. But: I don't think many use it. And why I am not using it is that it is only for one process at a time. Are you building an application where only one process will reach the database?

Do you have the fix for the error shown by the stress test? Or is it actually already in current rucksack? I've a modified snapshot of rucksack here which makes parallel reader transactions possible. The current official rucksack isn't particularily well suited for web applications, because it serializes all transactions. I've implemented a multi-reader single-writer transaction for rucksack and deployed several simple web apps using it (1-n rucksack accesses per request). In about a year running those apps I didn't have any lost data or other problems.

Perhaps we should throw our code together and put it up somewhere (Github?) for others to use.

> For a web-application we built and use elephant with the postgresql backend. It is scalable, built for multiple processes (even on different servers) and multiple threads and has caching so performance is ok. It has nothing to do with SQL, just uses postgres for storage to get advantage of the scalability. I read from your blog it is not installable with quicklisp, but for some applications the easiness of install is not the most important issue to consider.

It's a pity that elephant still seems to depend heavily on external libraries or systems. Last time I looked elephant still used FFI for serializing lisp-data. Rucksack is cool because it is actually nearly 100% just CL - its a really simple drop in persistence solution where others are always a PITA to install and maintain.

I'm currently quite deep in other works, but wanted to investigate the merits of "NOSQL" ideas in a CL only (or at least "mostly CL") implementation.

--
Jochen Schmidt
CRISPYLOGICS
Cross Media Solutions
Uhlandstr. 9, 90408 Nürnberg

Telefon +49 (0)911 517 999 82
Telefax +49 (0)911 517 999 83

mailto:info at crispylogics.com
http://www.crispylogics.com