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