Prevayler is an efficient and very simple way of providing application state persistency.
Essentially: - all the state is kept in memory, in native language data structures - whenever a write transaction is performed the system automatically serialises a description of the transaction so that it can be replayed later. - occasionally the whole state can be serialised to produce a snapshot - when the system restarts it reads in the last snapshot and replays all transaction since the last snapshot.
thanks for the explanation. but this means that there is one process permanently running and holding on to all the application state in main memory. if you want to shut down, move, or replicate that process, you need to get hold of its data, and if you can't communicate its data to worker processes, you have to communicate the work into the repository process. all limited by serialisation, unless that aspect is kept implicit by accross-the-board support for persistence and first-class communications. its a bit like pointers in haskell: just about everything a haskell program touches is a pointer (unboxing or shared constants are optimisations), but usually, haskell programs talk about the data being referenced, not about the references. if you want to share or forget the data, you move the references, and the system handles memory management behind the scenes. with orthogonal persistence, everything a program touches might persist, but usually, programs talk about the data being persistet (?), not about whether that data is currently temporary or in long-term storage. if you want to move such data between processes or storage areas, you move the reference, and the system handles serialisation/ communication/deserialisation behind the scenes.
Is this orthogonal persistence?
it doesn't seem so. but it does try to address the same issues, in an environment limited by its lack of support for orthogonal persistence. i used to have a long list of references to the area here: http://www.cs.kent.ac.uk/people/staff/cr3/bib/bookshelf/Persistence.html which might still give some overview of titles, but note that almost all of the urls are out-of-date or have disappeared entirely. lets see whether i can find some of them again: St.Andrews seems to have preserved some of its older groups' information, including publication lists (some of the publications are online as well): http://www-old.cs.st-andrews.ac.uk/research/publications.php?keyword=persist... http://www-old.cs.st-andrews.ac.uk/research/publications.php?keyword=reflect... and has a wiki, too: http://www-systems.cs.st-andrews.ac.uk/wiki/Persistence http://www-systems.cs.st-andrews.ac.uk/wiki/Linguistic_Reflection and there were some survey papers, including: Orthogonally Persistent Object Systems (1995) Malcolm Atkinson, Ronald Morrison; VLDB Journal http://citeseer.ist.psu.edu/atkinson95orthogonally.html many of the topics talked about in those papers will be more familiar to todays haskellers than to the general programming language audience of the time (first class procedures, type abstraction, existentials, runtime code generation, ...). but note that most of the material is old, so code might be in terms of algol variants, not haskell, compile-time reflection, not template haskell, runtime reflection, not meta-ml, reflection where generic programming would be sufficient, and so on.. and todays haskellers are certainly aware of the issues addressed in that old work on unifying database and programming language research: getting the advantages of databases into production code without the hassle of dealing with two separate and incompatible semantics and systems. instead of seeing databases as external to programming languages, they become integrated structures/features of the language. hth, claus