prevayler

Unnecessary Reading of Old Journal Causes ClassNotFoundException

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.3
  • Component/s: Code
  • Labels:
    None
  • Number of attachments :
    0

Description

This bug has very simple workarounds. It will probably be fixed in the next major release.

Report by William Pietri:

> Suppose in version 1 of the software I have a bunch of transaction
> A. In version 2, this transaction is removed. It seems like even if
> I snapshot as the last thing before shutdown and upgrade, Prevayler
> will still read the last journal, even though it doesn't need to.
> Won't this result in a ClassNotFoundException as it tries to load
> and discard the copies of transaction A in the journal?

Workarounds:

1) To keep the class of Transaction A around, even if it is no longer being used.

OR

2) To delete or move the old journal files to another directory.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. PRV-22 Unified "Serializer" interface

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Justin Sampson added a comment -

Ooh! The chunked encoding scheme I just described for PRV-22 would eliminate this problem as well, since transactions can be counted and skipped without actually deserializing them at all.

Show
Justin Sampson added a comment - Ooh! The chunked encoding scheme I just described for PRV-22 would eliminate this problem as well, since transactions can be counted and skipped without actually deserializing them at all.
Hide
Permalink
Justin Sampson added a comment -

Done. The last journal is still scanned, but transactions from before the last snapshot are simply skipped without being deserialized.

Show
Justin Sampson added a comment - Done. The last journal is still scanned, but transactions from before the last snapshot are simply skipped without being deserialized.
Hide
Permalink
Ron Lancaster added a comment -

In 2.2.005 it appears that the transactions prior to the final snapshot are still being read. I believe the following change to PersistentLogger.update() will resolve the issue:

final long initialLogFile = findInitialLogFile(initialTransactionWanted);

final long nextTransaction;
if (initialLogFile == 0 || initialLogFile < initialTransactionWanted)

{ nextTransaction = initialLogFile + 1; }

else

{ nextTransaction = recoverPendingTransactions(subscriber, initialTransactionWanted, initialLogFile); }

initializeNextTransaction(initialTransactionWanted, nextTransaction);

The important change is the check to see if initialLogFile is less than initialTransactionWanted. If so, then the next transaction is initialized.

If this looks correct, will someone please commit to source?

Thank you!

Show
Ron Lancaster added a comment - In 2.2.005 it appears that the transactions prior to the final snapshot are still being read. I believe the following change to PersistentLogger.update() will resolve the issue: final long initialLogFile = findInitialLogFile(initialTransactionWanted); final long nextTransaction; if (initialLogFile == 0 || initialLogFile < initialTransactionWanted) { nextTransaction = initialLogFile + 1; } else { nextTransaction = recoverPendingTransactions(subscriber, initialTransactionWanted, initialLogFile); } initializeNextTransaction(initialTransactionWanted, nextTransaction); The important change is the check to see if initialLogFile is less than initialTransactionWanted. If so, then the next transaction is initialized. If this looks correct, will someone please commit to source? Thank you!
Hide
Permalink
Justin Sampson added a comment -

Hi Ron,

The current logic is correct. The preceding journal file does have to be read, because it may contain the transaction we're looking for. For example, if you have a snapshot at 7 and the last journal is 3, that journal might contain transactions 3, 4, 5, 6, 7, 8, and 9. The transactions before the snapshot will be read and skipped but will not be deserialized.

Justin

Show
Justin Sampson added a comment - Hi Ron, The current logic is correct. The preceding journal file does have to be read, because it may contain the transaction we're looking for. For example, if you have a snapshot at 7 and the last journal is 3, that journal might contain transactions 3, 4, 5, 6, 7, 8, and 9. The transactions before the snapshot will be read and skipped but will not be deserialized. Justin
Hide
Permalink
Jacob Kjome added a comment -

This issue is addressed by changes Justin made in PRV-22. Closing this issue.

Show
Jacob Kjome added a comment - This issue is addressed by changes Justin made in PRV-22 . Closing this issue.

People

  • Assignee:
    Unassigned
    Reporter:
    Klaus Wuestefeld
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: