🚀 go-pugleaf

We are implementing a system using Lucid 4.0 and Mercury KBE system by
AIT.  The system involves a database which we will keep in Sybase
relational tables.  Mercury provides a mechanism for reading
relational tables as object instances.  We are using SUN-4 servers and
Sparcstations.

My question relates to the caching of object instances.  Our
application will consists of thousands of objects which will span
multiple relations (some of the attributes have multiple values).  The
users of the system will be provided with a set of tools for accessing
the data.  They may open multiple windows and multiple databases,
perform arbitrary queries and display the results in any of the
windows.  The issue is that a query may return a thousand objects, but
only 50 or 100 may be viewed at a time.

The fear is that the application process could grow to 100s of MBs
(the Mercury/Sybase image starts at 58MB and grows as you go) if the
objects are just loaded into memory. This approach would place the
burden on the memory management system.  The second approach is to
implement an Object Manager which maintains a list of primary keys
resulting from a query and a cache of the currently available
instances.  A request for an instance would be issued to the Object
Manager, who would then determine whether the object was already in
memory or whether it needs to be acquired from the database.

Has anyone else implemented a persistent object application in CLOS?
Has anyone tried to run multiple 100MB or larger images on the same
SUN server (we will use a 4/490 with 96MB RAM and 2GB disk)?  How well
does LUCID 4.0 perform with huge memory images?  Any comments on the
Object Manager cache?

Jus' fishin'...
Jay Nelson  (TRW)  jay@wilbur.coyote.trw.com