Re: Compayler 1.0
Christian Stein <[email protected]> Fri, 29 Aug 2014 10:24:46 +0200
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAJi8+g5gcej6gGzNrhB78G2ttb7Xi0_-N9KZvO=8P2etHyhW_Q@mail.gmail.com> |
--===============0094012973773967328== Content-Type: multipart/alternative; boundary=001a1133a9b8d0f2ef0501c0623e --001a1133a9b8d0f2ef0501c0623e Content-Type: text/plain; charset=UTF-8 Hi Justin, thanks for your reply, it actually encouraged me to code a proof-of-concept: PrevaylerEight.java [*0] May be someone wants to take a look and give this not synchronized version a try. I'm sure, that it needs more work to be consistent with the intended way of working. Deep copy of transactions, for example, or resizing the journal without restarting etc... hey, it's a prototype. ;-) Concerning new API usage: it was an opportunity for me learning them and Prevalyer in one go. And as I stumbled over memory mapped files, i wanted to plug them into the default implementation. I tried coding a custom Journal/Snapshot-Manager and ended up in rewriting most of the legacy code. The default implementation classes feel very "wired", hard connected ... it was easier for me to do it from scratch and skip synchronization entirely, because in my selector-driven server/client project, multiple threads are utilized/managed inside the business layer. This is a place, where the new stream [*1] API rocks! Cheers, Christian [*0] https://gist.github.com/sormuras/3fea6f6ade327b2a4249 [*1] http://docs.oracle.com/javase/tutorial/collections/streams/parallelism.html On Tue, Aug 26, 2014 at 2:07 AM, Justin Sampson <[email protected]> wrote: > 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 > --001a1133a9b8d0f2ef0501c0623e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Justin,<div><br></div><div>thanks for your reply, it ac= tually encouraged me to code a proof-of-concept: PrevaylerEight.java [*0]</= div><div>May be someone wants to take a look and give this not synchronized= version a try. I'm sure, that it needs more work to be consistent with= the intended way of working. Deep copy of transactions, for example, or re= sizing the journal without restarting etc... hey, it's a prototype. ;-)= </div> <div><br></div><div>Concerning new API usage: it was an opportunity=C2=A0fo= r me=C2=A0learning them and Prevalyer in one go. And as I stumbled over mem= ory mapped files, i wanted to plug them into the default implementation. I = tried coding a custom Journal/Snapshot-Manager and ended up in rewriting mo= st of the legacy code. The default implementation classes feel very "w= ired", hard connected ... it was easier for me to do it from scratch a= nd skip synchronization entirely, because in my selector-driven server/clie= nt project, multiple threads are utilized/managed inside the business layer= . This is a place, where the new stream [*1] API rocks!<br> </div><div><br></div><div>Cheers,</div><div>Christian</div><div><br></div><= div>[*0] <a href=3D"https://gist.github.com/sormuras/3fea6f6ade327b2a4249">= https://gist.github.com/sormuras/3fea6f6ade327b2a4249</a></div><div>[*1]=C2= =A0<a href=3D"http://docs.oracle.com/javase/tutorial/collections/streams/pa= rallelism.html">http://docs.oracle.com/javase/tutorial/collections/streams/= parallelism.html</a></div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,= Aug 26, 2014 at 2:07 AM, Justin Sampson <span dir=3D"ltr"><<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"">Christian Stein wrote:<br> <br> > I think, the prevayler project lacks an up-to-date "advertising&q= uot; web<br> > site with more examples, a wiki that's not labeled "old"= (may be<br> > transfering the old content to github? [*0]) and a more current<br> > release than one from the start of 2013.<br> <br> </div>There was a "new" wiki at some point. I extracted the "= ;old" wiki with<br> minimal formatting so we wouldn't lose it when migrating to the "n= ew"<br> site. That's also when the slick "new" logo appeared. :) Othe= rs<br> rearranged/migrated the site yet again after that, losing the "new&quo= t; wiki<br> but keeping the links to the "old" wiki pages... I'm not sure= who or why<br> that was.<br> <div class=3D""><br> > Or even an 3.0 version based on Java 8 with usage of java.util.time<br= > > inside Clock (why is the clock exposed by the Prevayler anyway?) and<b= r> > java.util.concurrent / java.nio et al inside the default<br> > implementation.<br> <br> </div>Would any of those actually improve anything? If Prevayler were writt= en<br> from scratch today I imagine those new APIs might be utilized, but I'm<= br> not aware of specific issues relevant to Prevayler that they have<br> improved upon. It would take some careful benchmarking and testing to<br> make sure that performance is actually improved without breaking<br> anything!<br> <div class=3D""><br> > May be, one can split the implementation regarding concurrent threads<= br> > like Java collections: have a not thread-safe implementation that can<= br> > be wrapped by a synchronized facade.....<br> <br> </div>Prevayler's synchronization logic is fairly subtle, and carefully= coded<br> to encompass the smallest scope possible, in support of pipelining and<br> batching of transactions for maximum throughput. Redesigning the<br> internals to support an unsynchronized mode and doing synchronization in<br= > a high-level wrapper would break a lot of what makes Prevayler awesome.<br> You might simply consider an alternative implementation of the Prevayler<br= > interface that does no synchronization or persistence at all, just for<br> testing or development purposes, but I doubt that the overhead of<br> synchronization would be much of an issue in such circumstances.<br> <div class=3D""><br> > Monday morning and a lot of thoughts. (-:<br> <br> </div>Very good! Keep at it. :) My comments above are intended as good-natu= red<br> challenges, not discouragement.<br> <br> Cheers,<br> <div class=3D"im HOEnZb">Justin<br> <br> ---------------------------------------------------------------------------= ---<br> Slashdot TV.<br> Video for Nerds.=C2=A0 Stuff that matters.<br> <a href=3D"http://tv.slashdot.org/" target=3D"_blank">http://tv.slashdot.or= g/</a><br> </div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________= __________________<br> To unsubscribe go to the end of this page: <a href=3D"http://lists.sourcefo= rge.net/lists/listinfo/prevayler-discussion" target=3D"_blank">http://lists= .sourceforge.net/lists/listinfo/prevayler-discussion</a><br> _______________________________________________<br> "Databases in Memoriam" -- <a href=3D"http://www.prevayler.org" t= arget=3D"_blank">http://www.prevayler.org</a><br> </div></div></blockquote></div><br></div> --001a1133a9b8d0f2ef0501c0623e-- --===============0094012973773967328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ --===============0094012973773967328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org --===============0094012973773967328==--