prevayler
  1. prevayler
  2. PRV-32

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

          Activity

          Hide
          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
          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
          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
          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
          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
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: