There is also a new backend for elephant based on postmodern(cl-postgres) called ele-postmodern. It is thread safe and process safe. It is in alpha state but is already used by two production web sites. It is not, like perec, an object relational mapper, but merely uses postgresql as a low level storage mechanism.

Even though I make this ad about the ele-postmodern backend, I believe that there is much to do in this area. We have plans to make a new even better persistence solution, where better means safe, highly scalable for lots of processes, good performance, nice high level features. Maybe you are interested in coordinating efforts?

/Henrik Hjelte

On 10/2/07, Samantha Atkins sjatkins@mac.com wrote:

Is WITH-CONNECTION getting threads out of a pool? It seemed to optionally to do that but my early reading also made me wonder if those were active connections or still had some overhead before they could be used. My own project idea was to take my ample (20+ years)

WITH-CONNECTION (and in fact any function/macro that deals with a connection) takes a POOLEDP argument. If it is non-NIL, a connection is recycled from the connection pool (if available). I don't *know* (in the sense I haven't really digged in that code or made thorough tests) if it works, but it *seems* to work and I kind of trust Marijn when he says it works.

of object persistence experience and produce a oodbms equivalent layer that can sit on any relational or many other underlying stores. The ideas is that this layer can be used by any language front end to as transparently as possible persist objects, structures and relationships between them with consistent transaction support, concurrency, caching and throughput mostly independent of front end language efficiency.

Well, Common Lisp thanks to CLOS and the MetaObject Protocol [1] seems like the perfect language to write something like that. Postmodern is also a good choice, because its "getting in the way" factor is very, very low (I think that keeping it maximally unobtrusive was one of Marijn's design goals).

The problematic part in writing an object persistency library remains (at least for me: I'm working on Submarine [2]) maintaining the balance between use comfort and efficiency. To make a long story short, making things happen naturally from the CLOS programmer (and I think any object system programmer) point of view sometimes leads to producing highly inefficient code...

For an extreme example, one could easily overload slot-setting/slot-reading by updating/reading the values of columns in some table, and that could be (from the programmer's point of view) quite comfortable. Of course, this would be inefficient to death. I still have hope, however, that there exist smart ways of generating nice SQL code under the hood. I am still astonished by the stupidity of some fragments of my own Postmodern/SQL code in Submarine, so I predict I still have plenty of room for optimization, without loosing the nice features or a rewrite from scratch :) After all, Common Lisp is such a nice language for generating code in lesser ;) languages, like SQL.

Obviously this layer needs to be seriously multi-threaded. I sometimes have doubts about doing this project in Lisp because things like threading support are not consistent and dependable on all platforms using non-proprietary Lisp. Lisp is attractive to me for the mileage I can get in the way of generated specialized code and on the fly refactoring and other reactive programming tricks. It also can come in very handy for offering a very full object query language that produces much more optimal code than less capable languages can support. But the meat of such a layer could certainly easily be done in C# (I most of that "meat" in Java a while back) with much more portability and some serious other advantages like being able to be used fully in a single process for any .net/mono capable language.

There are Bordeaux threads, which is a semi-standard thread compatibility layer between different CL implementations. Threads in CL remain a bit tricky, though.

Best regards,

-- Richard

[1] Bear in mind, however, that MOP is not standardized and its implementation may differ drastically between different CL implementations. Of course, there is Closer-MOP, but that doesn't solve all the problems (e.g. slot objects in Lispworks don't know which class they are belong to, while in SBCL they do).

[2] My very own object persistency library: http://common-lisp.net/project/submarine/. For the record, I *did* resist the temptation of advertising it in this thread ;-) (sometimes I have the feeling that writing an object persistency layer should be consed to every Lisp hacker's TODO list, the one already containing writing his/her own scheme dialect and planting a tree).