Hi, after some reading, testing and debugging, I think I understand how it works. So I thought write something if anyone is in the same situation:
- There are no nodes (I think) with a "conflict" state in a content repository. I searched the paths reported in my log with conflicts and found no indicator (special mixin, child nodes, properties, etc). The rep:MergeConflict is "added" by the AnnotatingConflictHandler in runtime so the ConflictValidator checks if the node "has" that mixin and then throws a CommitFailedException, discarding the changes that were about to be saved. It is not like that mixin is added to the node in the repository. - To avoid or minimize conflicts: 1. Try to keep the JCR sessions as short as possible. i.e. create the session, make changes, call session.save(), call session.logout. If you need to do something additional in the repository, a few lines after (maybe after some processing that could take some time), create the session again and repeat. 2. Try to use session.refresh(true) before saving, if you think that some significant time can pass between the login() and the session.save() call. 3. You could write your own conflict handler and add it when configuring your Oak or WhiteBoard instances. Only if you know what you are doing (i.e. you know how to resolve conflict in each one of the possible situations). By default, the AnnotatingConflictHandler instance will discard your changes and your commit will fail. The worst that will happen is that some changes were not persisted (if you are ok with that). Please check org.apache.jackrabbit.oak.plugins.commit.JcrLastModifiedConflictHandler. It seems like a good example to follow. 4. Enable the DEBUG level on org.apache.jackrabbit.oak.plugins.commit.MergingNodeStateDiff and org.apache.jackrabbit.oak.plugins.commit.ConflictValidator loggers if you want to have more information on the circumstances of a conflict that happened in a point of time. References https://cqdump.joerghoh.de/2015/11/02/aem-anti-pattern-long-running-sessions/ https://cqdump.joerghoh.de/2015/12/22/how-can-i-avoid-oak-writemerge-conflicts/ https://jackrabbit.apache.org/oak/docs/FAQ.html https://adapt.to/content/dam/adaptto/production/presentations/2015/adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf/_jcr_content/renditions/original./adaptTo2015-Conflict-handling-with-Oak-Michael-Duerig-with-comments.pdf Thanks. Jorge El mié, 5 oct 2022 a las 10:58, Jorge Flórez (<jorgeeduardoflo...@gmail.com>) escribió: > Hi, > > in a production log I have some messages like this one: > > javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in > /F/EDTG/2010286E/00_Hoja_Control_2017_T5.pdf > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:238) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:669) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:495) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:420) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273) > at > deployment.mpEcmEA.ear//org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:417) > > I have been reading and I think I got some understanding, but I still have > questions: > > 1 Does the past message mean that the node cannot be modified further in > any way? > 2 As far as I know, some conflict handlers are added to my JCR instance by > default: > RepMembersConflictHandler, JcrLastModifiedConflictHandler, > AnnotatingConflictHandler and one wrapper. If my guess is correct, the > "conflict" was managed by the AnnotatingConflictHandler which always > returns *Resolution.THEIRS* and adds rep:MergeConflict mixin to the node. > Does this mean that all I have to do is remove the mixin to get rid of > "OakState0001: Unresolved conflicts"? > 3 Or should I write my own handler that for example always returns > *Resolution.THEIRS > *and that's it? or in the handler I have to manually make the respective > changes in all of the events? > > I hope I have been clear. Thanks in advance. > > Regards. > > Jorge > >
