Re: large transaction sizes and rollbacks

On Fri, Mar 4, 2011 at 9:22 AM, Rick Ross <[email protected]> wrote:

> He's right, the transaction is written and fails.  If you restart the app,
> the transaction attempts to run again, and fails, ad infinitum.
>

Which isn't a problem, unless it's throwing an Error, which would crash the
app. Exceptions are fine, and ignored.

You have to manually block the transaction.  You have to do this with a
> listener (I forgot the name of the class), not just a file system check
> because the transactions can be written as bundles.
>

Well, if you're up for code changes you could just change the code of that
specific transaction class to start with "if (date.equals(BAD_DATE))
return;"!

HOWEVER, this is a very bad idea in general -- changing the behavior of
transactions that exist in the journal affects not only that transaction but
EVERY LATER transaction, because each of them runs against a different
initial state than it did originally. I always recommend taking a snapshot
before applying any code changes whatsoever so that no old transactions are
allowed to run with new code.

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org