PLOB! (Persistent Lisp OBjects!) is an Object Database, implementing orthogonal persistency for LISP and CLOS objects. It also contains important database features like transactions, locking and associative search over persistent objects. PLOB! mimics the features of CLOS' Metaobject Protocol (MOP) as far as possible, e.g. by its implemented self-describing persistent objects and support for class changes promoted dynamically to persistent objects (schema evolution)

PLOB! is available from (this link doesn't work, but this one does). Although free software, it depends on the POSTORE system from the University of St Andrews, which may not be. Anyone else know? PLOB! documentation available at this site .

Note: I can't get to respond - but the new SourceForge page is at

I'm madly trying to get U. of St. Andrews to answer my questions concerning licensing. I'm going to make them a fixed fee, unlimited use offer soon, just to see if I can get them to respond. I'm thinking of using PLOB in some commercial software I'm writing. (I'm the author of the questions to which Heiko was responding, below). --AlainPicard

Update -- after 2 months, I gave up on getting any answer from U of St. Andrews, and am now using Lispworks's RDB-CLOS bindings. The inability to licence POSTORE essentially orphans PLOB!, as it cannot be safely used in a commercial environment. This is a shame, as PLOB! is rather nice, IMO. --AlainPicard

I'm willing to pester U. of S.A. if you can share some information on who you tried to contact (assuming you got to a live person, or had a live person's email address) and how long ago you gave up trying. --Dan Moniz

Mail from Heiko Kirschke on the mailing list:

Subject:  Plob in production; was: RE: Mixing of metaobject classes  (Document
      link: Heiko Kirschke)

> Regarding PLOB in a production environment, what are your feelings about
> its appropriateness?  Is it stable?  Can it run for days on end?

Yes. I've tried to avoid the trap of using up resources over time which
are not given back to the system. For example, for the locking algortihm
the intermediate objects used for representing the locks are maintained
seperately from the other persistent objects in an explicit free list.
There are only very limited situations where objects are used up and
not deallocated after usage, for example when using compound keys on
btrees; this can also be avoided with some care in coding.

You should have some ideas in mind when using Plob in a production

1. The database itself is kept in virtual memory, i.e. the persistent
   layer implemented in the POSTORE library uses the virtual memory
   mechanisms of the underlying OS to implement persistent objects.
   For the sake of performance, the virtual memory is not flushed
   to disk at the end of a transaction in Plob's default

   This must be forced either:

   1.a. by evaluating plob-flush from time to time which
        forces a flush to disk every time it is called


   1.b. by setting the always-flush mode of Plob by evaluating
        (flush-mode :always) which forces a flush of virtual memory
        and all disk buffers so that the database on disk is always
        up-to-date. (flush-mode :always) must be evaluated once
        after the database has been opened.

   1.a. means that you have to do a flush by yourself from time to
   time, whereas in 1.b. Plob takes care for flushing at appropiate
   moments. 1.b. introduces more disk I/O. In 1994, this was a
   problem, but I think that now disk I/O has become so fast that
   using solution 1.b. is feasible.

2. For doing a database backup, the database should be closed.

3. Closing the database and restarting the database server from
   time to time (say once a week) definitely frees any resources
   which might have been allocated by let's say `unusual events',
   like orphaned database sessions etc. This can also be achieved
   by a call to (p-restart) on the client's side.

4. For large databases, Plob shows a tendency towards slowing down.
   Do a quick check by putting in the number of objects you expect
   your application will have and watch out for Plob's performance.

> (i.e. memory leaks, etc)?

I've taken as much care as possible to find and fix memory leaks, so
I'm pretty confident that there are no leaks left. At least in the
C code.

It is not that easy on the LISP side. Plob uses a cache for
performance and for maintaining the relation between a persistent
object in the database and its transient representation in the
LISP image. The cache is represented by two hash tables, one for
the mapping persistent to transient, one for transient to persistent.
Up to now, I've not found a satisfactory solution on using weak
hash tables for LWL or Allegro CL. This problem can only be bypassed
by evaluating (clear-cache) from time to time, which will result
in empty hash tables and a lost relation between a persistent object
and its transient representation.

> I'm worried as much by the postore library,

I've access to the POSTORE source code. The lib is pretty stable
now and uses malloc only in one place in a very controlled manner.
Since the POSTORE lib is now in use for at least 7 to 8 years,
it should not contain too much bugs any more.

> (to which I don't have source access) as plob itself.

You can find one reference at
<a href=""

*** Does anybody on the list have any experiences with Plob
in production or production-like environments? Input welcome ...

> Do you know anyone else who runs "serious" software with
> Plob as a back end?

Many people use Plob with cl-http. The feedback I've received up
to date is not that much, but it says that Plob runs pretty stable.


Topic: persistence