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

On Mon, Nov 7, 2011 at 1:11 PM, Robert Friberg <[email protected]>wrote:

> I don't really see the royal food taster pattern being of any use in a
> production environment as the size of the data grows. In livedb we do a
> rollback when a transaction fails unexpectedly. A rollback is a system
> restore up to just before the failing transaction. This way there is no
> performance penalty for well-behaved transactions, except those waiting for
> the rollback to complete. Of course, it hasn't happened yet in production :)
>

Right. The Prevayler purist position is that rollbacks are simply
unnecessary. If a transaction throws an exception, so be it. It must be
deterministic, so it will throw the same exception at the same point when
replayed.

Looking at the source code of prevayler.java i was surprised to see the
> sensitiveQuery parameter in one of the execute overloads. I would say all
> queries should be considered sensitive. Also I assume the prevalentSystem()
> method is the mechanism which allows these unsychronized reads. In livedb
> you cant get a direct reference to the prevalent system, it is completely
> encapsulated and access is only allowed through execute() overloads. Any
> returned data is cloned.
>

Nice. I've been tempted to clone data returned from transactions/queries,
but was reluctant just because people already complain about cloning
transactions. I definitely think it's the right thing to do, though.
Accessing the prevalent system directly is just asking for trouble.

One way to boost performance would be using a read/write lock instead of an
> exclusive lock for both reads and writes allowing multiple readers. In
> livedb, transactions have a prepare() method with read-only access executed
> using a shared upgrade lock. This helps keep the blocking updates short.
>

I've been skeptical about read/write locks actually boosting performance,
though they're a common request. Of course, java.util.concurrent locks are
actually higher performance than built-in synchronization anyway, so it's
probably a win just for that reason. A prepare() phase seems especially
unnecessary to me, though.

Naveen: I think transactions being modified during execution is bad design,
> their purpose is to carry the necessary information together with the logic
> to update the prevalent system. Also, consider keeping the execute() method
> thin by invoking behavioral methods on the prevalent system. This avoids
> the anemic model and transaction script anti-pattern.
>
> Also, stuff like printing to the console, logging, sending emails etc
> should be performed at the application level, not at the domain persistence
> level.
>

Absolutely agree. Thanks for jumping in. :)

Cheers,
Justin

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