PLOB! is available from http://www.lisp.de/software/plob/ (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 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 firstname.lastname@example.org 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. [...]