[hornetq-commits] JBoss hornetq SVN: r11188 - in branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl: dataformat and 1 other directory.

Author: borges Date: 2011-08-11 13:08:43 -0400 (Thu, 11 Aug 2011) New Revision: 11188 Modified: branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/JournalImpl.java branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/dataformat/JournalCompleteRecordTX.java Log: HORNETQ-720 Rewrite javadoc as old information was incorrect. Modified: branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/JournalImpl.java =================================================================== --- branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/JournalImpl.java 2011-08-11 17:08:09 UTC (rev 11187) +++ branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/JournalImpl.java 2011-08-11 17:08:43 UTC (rev 11188) @@ -1186,19 +1186,7 @@ /** - * <p>A transaction record (Commit or Prepare), will hold the number of elements the transaction has on each file.</p> - * <p>For example, a transaction was spread along 3 journal files with 10 pendingTransactions on each file. - * (What could happen if there are too many pendingTransactions, or if an user event delayed pendingTransactions to come in time to a single file).</p> - * <p>The element-summary will then have</p> - * <p>FileID1, 10</p> - * <p>FileID2, 10</p> - * <p>FileID3, 10</p> - * - * <br> - * <p> During the load, the transaction needs to have 30 pendingTransactions spread across the files as originally written.</p> - * <p> If for any reason there are missing pendingTransactions, that means the transaction was not completed and we should ignore the whole transaction </p> - * <p> We can't just use a global counter as reclaiming could delete files after the transaction was successfully committed. - * That also means not having a whole file on journal-reload doesn't mean we have to invalidate the transaction </p> + * Regarding the number of operations in a given file see {@link JournalCompleteRecordTX}. */ @Override public void appendCommitRecord(final long txID, final boolean sync, final IOCompletion callback, boolean lineUpContext) throws Exception @@ -2596,11 +2584,13 @@ // ----------------------------------------------------------------------------- /** - * <p> Check for holes on the transaction (a commit written but with an incomplete transaction) </p> - * <p>This method will validate if the transaction (PREPARE/COMMIT) is complete as stated on the COMMIT-RECORD.</p> - * - * <p>Look at the javadoc on {@link JournalImpl#appendCommitRecord(long)} about how the transaction-summary is recorded</p> - * + * <p> + * Checks for holes on the transaction (a commit written but with an incomplete transaction). + * <p> + * This method will validate if the transaction (PREPARE/COMMIT) is complete as stated on the + * COMMIT-RECORD. + * <p> + * For details see {@link JournalCompleteRecordTX} about how the transaction-summary is recorded. * @param journalTransaction * @param orderedFiles * @param recordedSummary Modified: branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/dataformat/JournalCompleteRecordTX.java =================================================================== --- branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/dataformat/JournalCompleteRecordTX.java 2011-08-11 17:08:09 UTC (rev 11187) +++ branches/HORNETQ-720_Replication/hornetq-journal/src/main/java/org/hornetq/core/journal/impl/dataformat/JournalCompleteRecordTX.java 2011-08-11 17:08:43 UTC (rev 11188) @@ -15,26 +15,23 @@ import org.hornetq.api.core.HornetQBuffer; import org.hornetq.core.journal.EncodingSupport; +import org.hornetq.core.journal.impl.JournalFile; import org.hornetq.core.journal.impl.JournalImpl; /** - * <p>A transaction record (Commit or Prepare), will hold the number of elements the transaction has on each file.</p> - * <p>For example, a transaction was spread along 3 journal files with 10 pendingTransactions on each file. - * (What could happen if there are too many pendingTransactions, or if an user event delayed pendingTransactions to come in time to a single file).</p> - * <p>The element-summary will then have</p> - * <p>FileID1, 10</p> - * <p>FileID2, 10</p> - * <p>FileID3, 10</p> - * - * <br> - * <p> During the load, the transaction needs to have 30 pendingTransactions spread across the files as originally written.</p> - * <p> If for any reason there are missing pendingTransactions, that means the transaction was not completed and we should ignore the whole transaction </p> - * <p> We can't just use a global counter as reclaiming could delete files after the transaction was successfully committed. - * That also means not having a whole file on journal-reload doesn't mean we have to invalidate the transaction </p> - * + * <p> + * A transaction record (Commit or Prepare), will hold the number of elements the transaction has in + * the current file. + * <p> + * While loading the {@link JournalFile}, the number of operations found is matched against this + * number. If for any reason there are missing operations, the transaction will be ignored. + * <p> + * We can't just use a global counter as reclaiming could delete files after the transaction was + * successfully committed. That also means not having a whole file on journal-reload doesn't mean we + * have to invalidate the transaction + * <p> + * The commit operation itself is not included in this total. * @author <mailto:clebert.suconic@jboss.org">Clebert Suconic</a> - * - * */ public class JournalCompleteRecordTX extends JournalInternalRecord { @@ -70,7 +67,7 @@ } buffer.writeInt(fileID); - + buffer.writeByte(compactCount); buffer.writeLong(txID);