PLOB! is available from http://www.lisp.de/software/plob/ (this link doesn't work, but this one does as well as a GitHub mirror). 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 www.lisp.de to respond - but the new SourceForge page is at http://sourceforge.net/projects/plob.
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 plob@lisp.de 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
environment:
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
configuration.
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
or
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="http://www.lisp.de/software/plob/plob-koehorst.html"
>http://www.lisp.de/software/plob/plob-koehorst.html</a>
*** 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 ObjectStore transaction