PERSISTENT LISP OBJECTS!| by Heiko Kirschke |
|
| It's funny I thought I should do things differently for a database, but Plob lets you do things in a Lisp way. | |
| -- M. A. |
CL-USER 3 > (defclass person ()
((name :initarg :name :index (btree :test equal)))
(:metaclass persistent-metaclass))
declares a class person with its instances being
persistent and an index for associative search on its slot
name (actually, the class metaobject which represents the
class person itself will become persistent, too). Using
some other statements will make ordinary LISP and structure objects
persistent. It is also possible to make CLOS objects persistent which
are out of the user's control, for example, instances where the
defclass defining the class is not available and cannot
be modified as indicated in the example above. Besides that,
PLOB! has the notion of persistent packages and persistent
symbols for binding persistent objects:
CL-USER 4 > (setf #!*a-person*
(make-instance 'person :name "Kirschke"))
will bind the persistent instance generated from the
make-instance call to the persistent symbol
*a-person*. Similar to transient packages and symbols, an
object can be bound to a persistent symbol and thereby gets persistent
and identifyable:
CL-USER 5 > (setf #!*a-string* "A persistent string.")
... some years and LISP processes later ...CL-USER 99 > #!*a-string*
"A persistent string."
PLOB!'s architecture is a true client/server-approach, communicating by UNIX' standard RPCs. The server administers a persistent object space; one or more clients can access the persistent objects contained in the persistent object space. The multi-user access is completely serialized, since the implemented transactions and locking algorithm results in an isolation level of 3 according to the SQL-92 definition. The server is a UNIX process running on one of the machines mentioned below; the clients are processes running one of the LISP systems mentioned below (especially, clients with different LISP systems can connect concurrently to one server). By using UNIX' standard RPCs, heterogenous operation is supported too, i.e. the server and client can run on different operating or LISP systems. Access to the persistent object space can be allowed or denied on a per-host level.
or, if the user didn't specify a transaction block, PLOB! will surround each access by a transaction internally. In the above example, embedding the code into a transaction assures that either all changes done to persistent objects in the block will be committed to the persistent object space or, e.g. in the case of an error at proceeding the statements in the block, none of the changes will be promoted to the database. Serialization between concurrent transactions is provided by the two-phase transaction model adopted within PLOB!CL-USER 6 > (with-transaction ()... lots of more code ...
(setf #!*a-string* "Next persistent string.")
(setf #!*b-string* "Second string."))
The precondition for a transaction to be well-formed is that each object accessed within a transaction is reserved for the accessor; this is accomplished by PLOB's hierarchical lock protocol. Locks can be requested on one of the levels slot, object or whole database with the modes read, write or read-only. Page locking is not supported, since this makes no sense for the heterogenous population found in an object-oriented database.
For indices, PLOB! has persistent btrees, which are used internally for various tables and are made available for the user's purpose too as shown already above in the person class example. It is also possible to use btrees directly:
will set *my-btree* to a persistent btree. The operations on persistent btrees are very similar to those of hash tables, with the difference of the keys being sorted. (Of course, LISP's hash tables are supported too; PLOB! infringes no mapping from hash tables to btrees.)CL-USER 7 > (setf *my-btree* (make-btree :test 'equal))
Bugfixes |
|
What do you want to debug today?TM |
| Book |
To: plob-discussion-request@lists.sourceforge.netFor unsubscribing, send an email with `unsubscribe' in the email's body to plob-discussion-request@lists.sourceforge.net:
--text follows this line--
subscribe
end
To: plob-discussion-request@lists.sourceforge.netThe end line is only necessary if there might be a following signature.
--text follows this line--
unsubscribe
end
Post your messages to plob-discussion@lists.sourceforge.net, plob-discussion-request@lists.sourceforge.net is used only for subscribing and administration. Purpose of this mailing list is to get support on installing and using PLOB, for reporting bugs, for getting announcements on new versions and for general topics on persistency, in this order. It is by intention a low-traffic mailing list.