Re: Making transaction calls act like a Java method call would
Robert Friberg <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <[email protected]> |
Hi all, Here are some thoughts on implementation and the discussions which have been going on here the past few days. 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 :) 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. 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. 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. Robert Friberg http://livedb.devrex.se/ +46733839080 Sent from my iPad On 7 nov 2011, at 18:48, "Naveen Chawla" <[email protected]> wrote: > Done. > > On 7 November 2011 22:39, Klaus Wuestefeld <[email protected]> wrote: >> Deep copy. It is a general principle of Prevayler to default the safest option. >> >> Klaus >> >> On Mon, Nov 7, 2011 at 3:03 PM, Naveen Chawla <[email protected]> wrote: >>> Ok, and should transaction-deep-copy or direct be the default? >>> >>> On 7 November 2011 22:09, Klaus Wuestefeld <[email protected]> wrote: >>>> Instead of calling it >>>> prevaylerFactory.configureDeserializeThenExecute >>>> >>>> please call it >>>> prevaylerFactory.configureTransactionDeepCopy >>>> >>>> Thanks, Klaus >>>> > > ------------------------------------------------------------------------------ > 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