[Prev][Next][Index][Thread]
Re: Distributed objects vs. generic functions and multi-methods
Vebjorn Ljosa wrote:
> But this opens up a whole can of worms. For a start, methods and
> subclass definitions will have to be propagated between nodes in a
> consistent manner. And because the methods can refer to symbols, they
> would have to be distributed as well. You would end up with a truly
> distributed Lisp instead of individual Lisps communicating through a
> middleware. Could be interesting, but I'm not yet convinced that it
> is a a good thing.
This is essentially one way a persistent object database can be
designed to work. I speak from my experience with Franz AllegroStore,
which is built on top of Excelon's ObjectStore. Multiple client
programs can `simultaneously' access each database, and that database
holds both instances and their class definitions. The first time a
an instance of a persistent class is referenced within each
transaction, the in-heap copy is compared for currency with the in-db
copy, and the differences reconciled with something akin to the usual
CLOS class updating protocol. The client application can control
whether to give precedence to the definition in the db (in order to
learn about updated definitions) or to the definition in the heap
(in order to propagate local changes to the database, and then
presumably to other distributed clients). The clients don't need to
be homogenious, i.e., they different OS and processor architecture
implementations can share a common database.
So ObjectStore more-or-less incidentally provides an environment
automatically suited to distributed applications, just as does almost
any multi-client database. All this incurs some overhead (and cost)
of course, and the real purpose of a persistent object database is to
provide a persistent object database, so one should indeed consider
the other alternatives for distribution if the persistent object
database component is not a useful part of the picture.
References: