Hi Jorge Thanks for your contribution and the PR. I will take a look today.
Kind regards Angela ________________________________ From: Jorge Flórez <jorgeeduardoflo...@gmail.com> Sent: Tuesday, December 6, 2022 19:54 To: oak-dev@jackrabbit.apache.org <oak-dev@jackrabbit.apache.org> Subject: Re: Unresolved Conflict Question EXTERNAL: Use caution when clicking on links or opening attachments. Hi, I am sorry for the extremely late reply. The last weeks have been very difficult. I created https://issues.apache.org/jira/browse/OAK-10025 and I think I created a pull request (I think, I am new in this matter). I added this to the ticket: https://github.com/apache/jackrabbit-oak/pull/786. Best Regards. Jorge El mar, 15 nov 2022 a las 7:52, Angela Schreiber (<anch...@adobe.com.invalid>) escribió: > hi jorge > > imho this would be a great addition to the oak documentation e.g. linked > into the section https://jackrabbit.apache.org/oak/docs/dos_and_donts.html > > would it be possible for you to create ticket and a PR for oak-doc? > > kind regards > angela > ________________________________ > From: Jorge Flórez <jorgeeduardoflo...@gmail.com> > Sent: Monday, November 14, 2022 21:32 > To: oak-dev@jackrabbit.apache.org <oak-dev@jackrabbit.apache.org> > Subject: Re: Unresolved Conflict Question > > EXTERNAL: Use caution when clicking on links or opening attachments. > > > 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 > > > > >
