jay@wiley.uucp (Jay Nelson) (11/14/90)
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
ray@cme.nist.gov (Steve Ray) (11/15/90)
It sounds to me like what you want is an object-oriented database management system. There are at least a half dozen commercial ones around, with three that I know of which are written in Lisp, namely Statice from Symbolics, Gbase from Object Databases, Inc., and Orion from Itaska. (Please note that I'm not recommending or endorsing any particular product). Have you looked at any of these? -- Steven R. Ray National Institute of Standards and Technology Building 220, Room A127 Gaithersburg, MD 20899 ray@cme.nist.gov (301) 975-3524
mike@ists.ists.ca (Mike Clarkson) (11/16/90)
In article <27401A1F.218F@wilbur.coyote.trw.com> jay@wiley.uucp (Jay Nelson) writes: >Has anyone else implemented a persistent object application in CLOS? Have you looked at Picasso? It's available by anonymous ftp from postgres.berkeley.edu Mike. -- Mike Clarkson mike@ists.ists.ca Institute for Space and Terrestrial Science uunet!attcan!ists!mike York University, North York, Ontario, FORTRAN - just say no. CANADA M3J 1P3 +1 (416) 736-5611
gregor@parc.xerox.com (Gregor Kiczales) (11/17/90)
A number of people have done different kinds of work connecting CLOS to a persistent database. At Symbolics they developed Statice, and OODB with a CLOS language binding. (Actually, at the time it was done, the binding was to New Flavors.) At HP Labs, Andreas Paepcke has done a lot of work looking at what it takes for a Metaobject Protocol to provide a foundation for connection CLOS to an persistent database. I believe he has papers in the last two year's OOPSLA conference proceedings.