Re: large transaction sizes and rollbacks

[email protected]
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
Thanks guys - really nice to get such high quality help!

Indeed the transaction will just rerun-fail-restore in exactly the same
way on all future occations. It does no real harm of course other than to
extend the start up time. I guess I just don't like the idea of a
transaction hanging around which is guarenteed to fail every time. I'll
check out what is involved with the listener but taking a snapshot really
seems the simplest solution - it actually didn't occur to me.

> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.