Re: Making transaction calls act like a Java method call would

Hi Naveen,

Prevayler deserializes your transaction, even the first time it is
executed, so that the baptism problem will fail fast, rather than
mysteriously only on system recovery.

A baptism-problem-aware user such as yourself, can be a little more
agressive and do what you were describing.

Klaus


On Thu, Nov 3, 2011 at 9:10 AM, Naveen Chawla <[email protected]> wrote:
> After trying to replace my Java method calls with the equivalent
> Prevayler transaction calls, some things no longer worked. In Java,
> when I passed in an object and manipulated its contents, it would come
> out as changed on the other side. That's because the copied reference
> inside the Java method is still pointing to the same data.
>
> In Prevayler, however, after a lot of head scratching, I found that
> its contents were unchanged on the other side.
>
> After even more head scratching, I found that Prevayler wasn't
> changing the data, but a deserialized copy of the data. This is of
> course intended, but isn't what I'm personally after, which is
> ordinary Java-method-call-like behaviour.
>
> By adding the following lines of code to the source, this is possible:
>
> In Capsule.java:
>
> As an instance member:
>
>        private transient Object _transaction=null;
>                        //Transient so that
>                        //upon recovery, this
>                        //field isn't used below:
>
> At the start of the existing constructor:
>
>        _transaction=transaction; //Hold it
>
> And at the beginning of the "executeOn" method:
>
>        //Instead of just:
>        //Object transaction = deserialize(journalSerializer);
>        //Use:
>
>        Object transaction;
>        if(_transaction!=null){ //i.e. capsule has just been
>                                //constructed, not recovered:
>
>                transaction=_transaction;
>        }
>        else{   //i.e. capsule has been recovered (where _transaction
>                //would be null because it is transient), or any other
>                //case where _transaction is null:
>
>                transaction = deserialize(journalSerializer); //as before
>        }
>
> //before execution...
>
>
> Anyone think this is a bad idea? I don't see this version as carrying
> any extra risks or side effects. The need to follow the Golden Rule of
> Prevayler: that if you want your prevalent system to be fully
> recoverable, it must never be manipulated via any reference outside of
> the "prevalentSystem" variable provided in transactions' "execute..."
> methods, is exactly the same as before. The strict transaction
> filtering also exactly the same. The only difference is that
> transactions can follow the more expected Java methods behaviour in
> terms of things passed in. Recovery only requires the initial snapshot
> of the variable, not its final state, right? That final state might be
> useful for subsequent things in the app (which it was, in my case).
> Any reason why this shouldn't be default in Prevayler?
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org