Re: paper on Prevayler

Hi,

I remember quite a while back there was much discussion about Command vs
Transaction. Eventually Command became Transaction.
The paper seems to be using these interchangeably. It even refers to a
Transaction design pattern in [Gamma 1995].
Raft looks to be dealing with Commands.
However, others
<https://github.com/eventstore/eventstore/wiki/Event-Sourcing-Basics>
prefer Transactions while treating Commands as a [subtly] different concept
(domain *events* as opposed to actions). In any case, the linked resource
(EventStore) has a few concepts that may help with this paper.


Tasos


On 6 August 2014 03:00, Justin Sampson <[email protected]> wrote:

> 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
>

------------------------------------------------------------------------------
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