2012/2/10 Robert Friberg <robert.friberg@devrex.se>

> Objects in memory + prevalence tool = prevalent system (or layer)

*Objects* in memory?
Prevalence doesn't require objects. The system in memory could have any representation. The same goes for the transaction journal, transactions can have any representation as long as they can be reinterpreted to restore the system.

agreed :)



What if the architecture is component or service-oriented?

still a layer to me..

This post is really cool..

And I'm with Klaus.. I've saw people creating prevalent systems (some very simple.. but still) and giving other names..

Maybe we can create a wiki about prevalence.. http://prevalence.io There's a lot of misconception about prevalence engines and styles


We use the term Model for the in memory database and if I recall correct, prevayler uses Transaction.executeTransaction(Object system). The parameter name "system" is generic enough but could be confused with the "Prevalent System" which includes the engine (tool) according to your definition. I think the original intention was:

       Prevalent system + engine = prevalence layer

Also, I'm uncomfortable with Transaction, in the rdbms world queries are also transactions. Instead we say Command, CommandWithResults and Query which all inherited abstract Transaction.

Our execute was Command.Execute(Model graph), currently it is Command.Execute(Model model).
We changed from graph because it implies objects (object graph).

I'll can elaborate on why we chose Model but I'll save that for later post.
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
"Databases in Memoriam" -- http://www.prevayler.org