Re: paper on Prevayler

Neat! Where do you plan to publish this (journal, website, etc.), and what is your intended/desired audience?

As for references, the new hotness these days is Raft <http://raftconsensus.github.io/>, a true-clustering prevalence layer. I'm pretty excited about it. They don't use the term "prevalence," of course -- they use the term "replicated state machine," which is the traditional description of this approach in the academic world, going back at least to Paxos from the late 1980s.

The idea of lazy evaluation or continuation passing is closely related to "eventual consistency." You persist one change that _guarantees_ additional changes will occur eventually. There's a lot of helpful discussion about this kind of eventual consistency in the Domain-Driven Design community.

I'm surprised by Karl's comment that business logic inside a transaction is "horrible." Isn't that the whole point of Prevayler? That it allows you to do "real" OO programming, with business logic encapsulated in domain objects? It kind of defeats the purpose to push business logic back onto the client. Prevayler transactions are inherently fast, even with significant business logic, _because_ it's all in memory in a single process.

Indeed, I disagree with the assertion in the draft that being confined to main memory is the main limitation of prevalence. That's not a limitation, it's an architectural principle! In my mind, the main limitation of prevalence is the programmer's responsibility to avoid nondeterminism in the code. For example, I had totally forgotten about floating-point optimization as a source of nondeterminism until reading it in your draft.

The statement in the draft that "not writing queries in the journal saves a little time when the query is executed, and saves a lot of time when the journal is replayed," seems backwards to me. Executing a query is usually tiny (nanoseconds), whereas writing it to disk is huge (centiseconds). Is your point that _lots_ of queries bloat the journal?

Another statement that seems a little off in the draft is that "the prevalent system can easily time transactions and store their times in the journal." Journaling happens _before_ execution, so execution times don't go in the journal. If you were to collect them, they would go in some separate kind of log. The timestamps in the journal represent when the transaction was submitted to the prevalence manager.

One additional pattern you might consider including is external blob storage. If users are uploading photographs, you probably don't want to store them directly inside the prevalent system. Instead, you save uploaded files directly on disk and then store a hash plus some metadata inside the prevalent system.

Cheers,
Justin
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org