Re: So why are things being executed twice on every transaction?

Yes, it's the food taster. It can be turned off easily via
PrevaylerFactory.configureTransactionFiltering(false), no code changes
required.

The food taster has nothing to do with atomicity and consistency. Those are
preserved just fine without the food taster, as long as your code is
deterministic, which is required anyway. It just lets you be sloppy about
exception handling in your code.

Prevayler purists don't really like the food taster for that reason, but
it's a nice example of what the prevalent architecture can provide if you
follow its rules (such as not depending on references being preserved
during transaction execution).

You should never care whether a transaction is executed multiple times,
because Prevayler is responsible for replaying transactions as needed (or
"preplaying" in the case of the food taster). Doing I/O (such as writing to
System.out) is explicitly verboten, so don't be surprised that weird things
appear to happen when you do.

Cheers,
Justin


On Sun, Nov 6, 2011 at 6:52 PM, Fabio Roger <[email protected]> wrote:

> What if, inside your transaction, an exception is thrown? you wouldn't
> now what the transaction already changed before throwing, right?
>
> So, prevayler makes sure the transaction can execute properly (without
> throwing an exception) by executing it first on a copy of your object
> model, the so called "food taster".
>
> If you can live without consistency and atomicity, then just turn off
> the food taster. Which is strongly discouraged.
>
> Fabio
>
> On 7 November 2011 01:27, Naveen Chawla <[email protected]> wrote:
> > Put a System.out.println in a transaction and it's outputted twice.
> > It's preventing my direct-transaction version from working properly
> > (e.g. if I add 1 to something, it ends up adding 2). On the
> > deserialize-then-execute version it has no effect on the output,
> > because it's carrying out on a deserialized copy each time.
> > Nonetheless, isn't it a little wasteful? I mean, isn't it making
> > Prevayler run twice as slow as it could? Meaning couldn't it be
> > carrying out its business once instead of twice?
> >
> > Upon examination I found it's:
> >
> > 1. the "royalFoodTaster.receive(timestampCopy);" in
> > "StrictTransactionCensor.java" (line 31)
> > 2. the "notifySubscribers()" call at the end of
> > "publishWithoutWorryingAboutNewSubscriptions()" in
> > "CentralPublisher.java" (line 65).
> >
> > Commenting out either line fixes things. What is the ideal
> > configuration for now in your view?
> >
> >
> ------------------------------------------------------------------------------
> > 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
>

------------------------------------------------------------------------------
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