Re: Postvayler

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