Re: Compayler 1.0

Justin Sampson <[email protected]> Tue, 26 Aug 2014 00:07:35 +0000
Newsgroups gmane.comp.java.prevayler
Message-ID <0FD072A166C6DC4C851F6115F37DDD2763EE2FB4@sm-ex-01-vm.guidewire.com>
Christian Stein wrote:

> I think, the prevayler project lacks an up-to-date "advertising" web
> site with more examples, a wiki that's not labeled "old" (may be
> transfering the old content to github? [*0]) and a more current
> release than one from the start of 2013.

There was a "new" wiki at some point. I extracted the "old" wiki with
minimal formatting so we wouldn't lose it when migrating to the "new"
site. That's also when the slick "new" logo appeared. :) Others
rearranged/migrated the site yet again after that, losing the "new" wiki
but keeping the links to the "old" wiki pages... I'm not sure who or why
that was.

> Or even an 3.0 version based on Java 8 with usage of java.util.time
> inside Clock (why is the clock exposed by the Prevayler anyway?) and
> java.util.concurrent / java.nio et al inside the default
> implementation.

Would any of those actually improve anything? If Prevayler were written
from scratch today I imagine those new APIs might be utilized, but I'm
not aware of specific issues relevant to Prevayler that they have
improved upon. It would take some careful benchmarking and testing to
make sure that performance is actually improved without breaking
anything!

> May be, one can split the implementation regarding concurrent threads
> like Java collections: have a not thread-safe implementation that can
> be wrapped by a synchronized facade.....

Prevayler's synchronization logic is fairly subtle, and carefully coded
to encompass the smallest scope possible, in support of pipelining and
batching of transactions for maximum throughput. Redesigning the
internals to support an unsynchronized mode and doing synchronization in
a high-level wrapper would break a lot of what makes Prevayler awesome.
You might simply consider an alternative implementation of the Prevayler
interface that does no synchronization or persistence at all, just for
testing or development purposes, but I doubt that the overhead of
synchronization would be much of an issue in such circumstances.

> Monday morning and a lot of thoughts. (-:

Very good! Keep at it. :) My comments above are intended as good-natured
challenges, not discouragement.

Cheers,
Justin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org