jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Boston (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1813) Invalid journal records during XATransactions
Date Wed, 04 Mar 2009 17:19:56 GMT

    [ https://issues.apache.org/jira/browse/JCR-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678795#action_12678795
] 

Ian Boston commented on JCR-1813:
---------------------------------

Will this get applied back to 1.4 ?

I have tried Extending/Replacing ClusterNode to stop it emitting empty journal records with
JTA transactions, and because of all the protected, final methods, its not possible. I haven't
tried aspects yet, but dont really want to, and analyzing the byte stream going into the DB
is just going to be a pain.

It would be a shame to run from patched/forked version of Jackrabbit.

I also tried 1.5, but it doesn't appear stable enough yet,


> Invalid journal records during XATransactions
> ---------------------------------------------
>
>                 Key: JCR-1813
>                 URL: https://issues.apache.org/jira/browse/JCR-1813
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: clustering, jackrabbit-core
>            Reporter: Stephane Landelle
>            Assignee: Jukka Zitting
>            Priority: Critical
>             Fix For: 1.5.0
>
>
> During the prepare phase of a XATransaction, XAItemStateManager.prepare calls ShareItemStageManager.beginUpdate
that, in case of a ClusterNode, calls ClusterNode.updatePrepared that does a ChangeLogRecord.write().
> This last method is located in ClusterRecord and systematically write the begin and the
end of the journal record.
> As a consequence, useless corrupted records are written in the journal everytime a transaction
ends without jackrabbit update! This causes polution of the journal, as other cluster nodes
try to sync with the corrupted updates and fail doing so as ClusterRecordDeserializer can't
deserialize it (the record identifier is empty).
> ChangeLogRecord (and even other ClusterRecord implementations too) should only write
if there's effective updates.
> I propose the following solution:
> *) add the following method in Changelog so clients can know if there's effective updates:
>     public boolean hasUpdates() {
>     	return !(addedStates.isEmpty() && modifiedStates.isEmpty() && deletedStates.isEmpty()
&& modifiedRefs.isEmpty());
>     }
> *) change ClusterRecord with:
>     public final void write() throws JournalException {
>     	
>     	if (hasUpdates()) {
> 	        record.writeString(workspace);
> 	        doWrite();
> 	        record.writeChar(END_MARKER);
>     	}
>     }
>     
>     protected abstract boolean hasUpdates();
> *) implement hasUpdates for every ClusterRecord implementation:
>  ----> ChangeLogRecord:
>     protected boolean hasUpdates() {
>     	return changes.hasUpdates() || !events.isEmpty();
>     }
>  ----> LockRecord and NamespaceRecord:
>     protected boolean hasUpdates() {
>     	return true;
>     }
>  ----> NodeTypeRecord:
>     protected boolean hasUpdates() {
>     	return !collection.isEmpty();
>     }
> Best regards,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message