Re: paper on Prevayler

Thanks a lot for your comments!  I hadn't connected prevalence with
consensus, but of course they are closely related.   My PhD work 30 years
ago was on distributed consensus but I quit paying much attention to that
area after the 80s were over.   I studied Lamport's work closely for
awhile, but never figured out Paxos.   One of the reasons I didn't connect
them was that the prevalent systems I have built have never been
distributed.   The only system using prevalence that I have used and that
was replicated was Croquet (which I plan to include as an example).   I'm
working on a system now that will become replicated, but prevalence is just
a tiny part of this system, and (for me) not the most interesting.  One of
the big advantages of prevalence is that it is so simple.  "Simple" means
you can ignore it most of the time.

Distributed consensus tends to focus on fault-tolerance.    When people
talk about "prevalence" they usually mean making things fast and simple by
avoiding disk.   So, though these have a lot in common, they tend to
emphasize different aspects.

The first place for the paper is at SugarLoafPLoP, a patterns workshop in
Brazil.   It will probably get sent to a variety of venues until we are
happy with it.  Somewhere along the line, we'll figure out a good journal
for it.   But the real target audience is developers, and so the most
important publication venue will be the web, where they can find it easily.


On Tue, Aug 5, 2014 at 9:00 PM, Justin Sampson <[email protected]>
wrote:

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

I was surprised, too.  I bet that he has a different definition of business
logic than we do.   This is probably an idea that needs elaborating.


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

It is a limitation if the amount of data you need is bigger than memory.
I like your suggestion of adding external storage as a pattern.   It is one
way to deal with the memory limitation.  My applications have never needed
it, but I bet it is fairly common.

I agree that the need for nondeterminism is as important as the limitation
on memory.   One of my weaknesses when writing is a tendency to give
priorities, such as "the main limitation", when they are not real.   On
most of the projects that I used prevalence, memory wasn't a problem.   I
ran a server for years that always ran on the oldest machine in my lab, and
when it started to get slow because it was running out of memory, I'd move
it to a somewhat newer machine with more memory, and throw out the old
server.  When it was obvious that we had more data than would fit in
memory, we would usually use a real database.

Nondeterminism is an architectural principle, too, with lots of benefits
(and costs).   Testing nondeterministic programs is much harder than
testing deterministic ones.   I have a lot experience with Smalltalk, and
Sets and Dictionaries in Smalltalk often lead to nondeterminism.  I also
experience with parallel programming.

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

I'm not sure exactly what my point was.  When I said "executing a query" I
meant to include the time to write it to the journal.  Usually there are a
lot more queries than there are transactions that change state.   I think
what I really meant was that the time saved would probably be more
noticeable when replaying the journal than when creating it in the first
place, but right now I don't remember why I thought that.


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

Yes.  What I really meant was that since we already have some mechanism for
ensuring that all transactions get written to a journal, we can use that
same mechanism for collecting timing information.  You are probably right
that you don't want to put it in the journal, but in some other log.  This
is more a function of the prevalence manager than the journal.

If performance is a problem (and often it isn't; prevalent systems are
often so fast that you never have to worry about it) then you need to
measure to find your bottlenecks.  The system I am working on now is
written in Groovy.   Although Groovy is a JVM language, the usual Java
performance monitoring tools don't work too well with Groovy because they
all end up showing you only the Groovy reflective run-time system.   So, I
am thinking I will have to roll my own performance  tools.

-Ralph Johnson

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