[Cl-perec-devel] Special requirements

[Attila Lendvai]

hi,

> I'm contemplating moving from Elephant to cl-perec.
>
> My project has some special requirements:
>
>  * Persistent objects and values are accessed by multiple threads.
>
>  * Persistent objects and values are accessed by multiple processes.


i'm not sure what you mean by processes. i assume OS processes and OS
threads here, so multiple threaded lisp vm's.

in perec persistent-objects are EQ inside a transaction, but separate
transactions can not share anything, not even inside a lisp vm. there
are two primitives to deal with this:

 - REVIVE-INSTANCE which works on a place and can "import" a "dead"
   instance from a previous already closed transaction

 - LOAD-INSTANCE which can "import" an instance into the current
   transaction (by loading it from the db, or if requested copying the
   cached slots from the dead instance without checking the db)

so, object identity in perec means that persistent instances are EQ
inside a transaction but otherwise if you want to check object
identity then you need to EQL check the id-of slot of the instances.


>  * Processes share a central storage 'ITEMS'. Additionally, each
>    process has a private storage 'WORLD'.
>
>  * Objects from the central storage need to be copied from ITEMS
>    to WORLD on a regular basis, including their associations
>    (I currently do this with a recursive clone-by-value).


perec is an rdbms mapper that helps you transfer data from/to the
database. this also defines your possibilities. so, you can either
separate your worlds using rdbms associations or useing different db
instances.

we use the former in our setup: we have 9 nodes in a cluster, each
node has a cluster-node instance looked up by the machine name when
the node starts. some of the persistent state is associated to these
instances.


> With this in mind, two questions:
>
>  Will cl-perec in its current state cope with this?
>  In negative case, are there workarounds?


i'm not sure about your requirements, but maybe the descriptions above
give you a picture.


>  What happens when I have a schema change and I update
>  the live processes one by one?


bad idea... might work in progressive changes (e.g. making a column
bigger), but what happens if the first restarted instance drops a
column the others are expecting to be there...?


> Can I defer (or entirely cancel) storage of an object until
> some point after MAKE-INSTANCE?


(make-persistent (make-instance 'foo :persistent nil))

but the multiple sides of associations are not working yet in
transient instances (iow, transient collections are not yet
implemented to store changes made to an association of a transient
instance)

hth,

-- 
 attila