Re: Postvayler

i guess it can be done with a custom classloader, runtime instrumentation.
but thats not a priority in my todo list at the moment.

to tell the truth, i was expecting more interest and contribution to this
project. strange. it still seems as a good idea to me.

r a f t
On Dec 7, 2013 7:43 PM, "hakan eryargi" <[email protected]> wrote:

> hi Flavio,
>
> thanks for motivating words:)
>
> yes, it would be fun to see the benchmark results of Postvayler. I would
> expect it perform slightly worse than Prevayler, because of the overhead by
> the pool and reflection based method calling. Postvayler requires an extra
> instrumentation step, how can it be done in those tests?
>
> btw, I've found and fixed a flaw in preventing GC.
>
> cheers,
> hakan
>
>
> On Fri, Dec 6, 2013 at 8:07 PM, Flavio W. Brasil <[email protected]>wrote:
>
>>  Hi Hakan,
>>
>> This effort looks promising, congratulations! :)
>>
>> You could also use the databen.ch project to test the Postvayler
>> consistency/scalability. I'm really interested on the results.
>>
>> Cheers,
>>
>> --
>> Flavio W. Brasil
>>
>> On Friday, December 6, 2013 at 7:02 PM, hakan eryargi wrote:
>>
>> I believe the project has reached the proof of concept state:)
>>
>> I've extended the bank sample with accounts and money transfers and made
>> another bank sample which emulates instrumentation (ie, manually added
>> injected code) that helped a lot to visualize what is going on.
>>
>> adding objects to pool with a reliable id was a bit tricky but I guess
>> I've managed it with a special transaction which behaves different at
>> regular run and recovery time. see ConstructorTransaction for some details.
>>
>> allowing garbage collection with a WeakValueMap is also done. there is
>> also a trick here to trick GC not to garbage collect target objects before
>> we're done. see GCPreventingPrevayler for some details.**
>>
>> I've made two tests:
>> 1. run the same sequence of thousands of operations on both persisted and
>> non-persisted instances and checked the results for equality. this also
>> includes closing prevayler, recovering and going on. all seems good.
>> 2. run thousands of operations with many threads. no objects missed. I
>> wish to have a multi-threaded check final result test similar to first one
>> but I couldnt figure how.
>>
>> next things:
>>  * scan all reachable @Persistent classes. at the moment generic
>> parameters (like collection types) is not parsed. I'm planning to scan all
>> packages of all reached @Persistent classes. this still does not guarantee
>> all required classes is instrumented (some one can extend a @Persistent
>> class in a totally different package), but there is a run time check to
>> catch that condition
>> * proper encapsulation. at the moment lots of things is public and anyone
>> can crash the system with a simple cast and java call
>> * more tests
>> * maybe a better trick to prevent GC
>> * cleanup and optimize compiler code
>> * ant build.xml (or maven?)
>> * an ant task for compiler
>> * support for spring dependency injection (at least injecting root as a
>> bean to other spring beans)
>> * some documentation
>> * adapt prevayler samples to postvayler
>> * what else?
>>
>> any feedback is welcome. please have a look at the samples (especially
>> the emulated sample) and speak up:)
>>
>> cheers,
>> r a f t
>>
>> ** after very very long multi-threaded runs sometimes an object is missed
>> (garbage collected). this happens very seldom and I suspect this is related
>> to JVM's runtime optimization. It may be detecting that our trick to
>> prevent GC is a noop and removing the call.
>>
>>
>> On Mon, Dec 2, 2013 at 11:57 PM, hakan eryargi <[email protected]>wrote:
>>
>> runtime bytecode injection isnt a current objective. it may be possible
>> later or not, doesnt really matter in this stage. pre-instrumented classes
>> is good enough for now, like jibx.
>>
>> come on, you should have some faith in flying spagetti monster man:)
>>
>> seriously, if someone sees a flaw, which cant be done, please speak up,
>> so i wont spend unnecessary hours. to me all seems good for now.
>>
>> btw, details are constantly changing and evolving. i've shared the
>> project in a very early stage for discussion
>>
>> r a f t
>> On Dec 2, 2013 10:52 PM, "Naveen Chawla" <[email protected]> wrote:
>>
>> Hakan, Congratulations for carving out the time to attempt this.
>>
>> How easy do you think it would be to instrument the object, when it is
>> passed in, to simply journal all changes to non-transient fields, and batch
>> them into single journal entries when they occur during a synchronized lock
>> over the prevalent object?
>>
>> Can it all be done with run-time instrumentation from start to finish,
>> such that no annotations are necessary?
>>
>>
>> On 1 December 2013 23:12, hakan eryargi <[email protected]> wrote:
>>
>> i'm experimenting with the idea. so far not bad. just put what I've done
>> to GitHub. any suggestions, critics and contributions are welcome:)
>> https://github.com/raftAtGit/Postvayler
>>
>> apologies for the name, it sounded like a nice word play:)
>>
>> to run the sample, run the Compiler class
>> with raft.postvayler.samples.bank.Bank argument and then run
>> raft.postvayler.samples.bank.Main
>>
>> how it works:
>> compiler injects bytecode to root class and all @Persistent classes that
>> can be accesible* from root.
>>
>> root class contains an injected object pool, where each @Persistent class
>> is assigned a Long id and put into this object pool when created. this pool
>> will be* a WeakValueMap so objects which are not attached to root will be
>> garbage collected at some time.
>>
>> each @Persist method in a @Persistent class is instrumented like this:
>> @Persist
>> ReturnType doSomething(someParams) {..}
>>
>> doSomehing is copied to __postvayler__doSomething(..). the original doSomehing
>> becomes:
>>
>> ReturnType doSomething(someParams) {
>>     if (!there is postvayler context)
>>         return __postvayler__doSomething(..);
>>     if (we are in a prevayler transaction)
>>         return __postvayler__doSomething(..);
>>     return prevayler.execute(new MethodTransaction(..));
>> }
>>
>> the arguments to doSomehing(..) is transformed in MethodTransaction such
>> that references to @Persistent objects are replaced with Reference's,
>> which will later be restored from object pool. seems as this also solves
>> the Baptism problem.
>>
>> looks good to me for now:)
>>
>> cheers,
>> *r a f t*
>>
>> * not implemented yet
>>
>> On Wed, Nov 27, 2013 at 11:07 AM, Naveen Chawla <[email protected]>wrote:
>>
>> Sure, here:
>> http://docs.oracle.com/javase/tutorial/java/generics/methods.html
>>
>> As for consistency, any multi-changes explicitly synchronized over
>> prevalentObject can be auto-batched.
>>
>>
>> On 27 November 2013 00:25, Klaus Wuestefeld <[email protected]> wrote:
>>
>> > It is ordinary generic method syntax.
>>
>> Could you point me to some doc on this syntax? I couldnt find it here:
>> http://docs.oracle.com/javase/tutorial/extra/generics/methods.html
>>
>> > The beginning and end of a transaction would simply be any change to any
>> > non-transient field.
>>
>> Suppose a transaction needs to update two fields to be correct but the
>> system crashes after the first. Will the system not be inconsistent on
>> recovery?
>>
>> Klaus
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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
>>
>>
>

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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