[
https://issues.apache.org/jira/browse/JCR-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641319#action_12641319
]
ppakulski edited comment on JCR-1775 at 10/21/08 2:51 AM:
----------------------------------------------------------------
I've created custom PM by simply overriding one method, to be able to track the
sequence of stored changes :
public synchronized void store(ChangeLog changeLog) throws
ItemStateException {
super.store(changeLog);
log.warn("STORE :" + getSchemaObjectPrefix() + ": " + changeLog);
}
Then I run checkout/checkin operation on single node :
1) without transaction
checkout
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
checkin
11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
2) checkout/checkin in transaction
11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=1}
Checkout/checkin in single JCR transaction still consist of 3 database level
transactions,
Moreover when using transactions, as you can see from the logs changes in
workspace are persisted first before storing changes in the version storage.
This is probably because of order of txResources in XASessionImpl class as
described in JCR-631.
was (Author: ppakulski):
I've created custom PM by simply overriding one method, to be able to track
the sequence of stored changes :
public synchronized void store(ChangeLog changeLog) throws
ItemStateException {
super.store(changeLog);
log.warn("STORE :" + getSchemaObjectPrefix() + ": " + changeLog);
}
Then I run checkout/checkin operation on single node :
1) without transaction
checkout
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
checkin
11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
2) checkout/checkin in transaction
11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=1}
Checkout/checkin in single JCR transaction still consist of 3 database level
transactions,
Moreover when using transaction changes in version storage are persisted first
before storing changes in the workspace.
This is probably because of order of txResources in XASessionImpl class as
described in JCR-631.
> Transaction-safe versioning
> ---------------------------
>
> Key: JCR-1775
> URL: https://issues.apache.org/jira/browse/JCR-1775
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core, transactions, versioning
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.5.0
>
>
> I've been working on a partial fix to JCR-630. Instead of implementing fully
> transactional versioning (i.e. a checkin will disappear when a transactin is
> rolled back), I'm ensuring that all versioning operations within a
> transaction will leave the version store in a consistent state even if the
> transaction otherwise fails at any point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
