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=persistence
http://www-old.cs.st-andrews.ac.uk/research/publications.php?keyword=reflection
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
