[
https://issues.apache.org/jira/browse/SLING-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177996#comment-15177996
]
Robert Munteanu commented on SLING-5582:
----------------------------------------
Thanks for the report. A couple of comments
* I see from the stacktrace that this is not the default Eclipse plugin, but
running in IntelliJ. Does this happen with Eclipse as well?
* I looked at the code in the {{AddOrUpdateNodeCommand}} and there's only a
single {{Session#save}} call, when the node primary type is changed . Can you
confirm that in your scenario {{Session#save}} is invoked in addition to the
final one from {{JcrCommand#execute}}?
* I would still need a unit test 'proving' this problem as I can't reproduce it
and the content sync code is complicated enough for a test to be the only guard
against regressions
> DAM Updates fail due to race conditions with Workflows in AEM
> -------------------------------------------------------------
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
> Issue Type: Bug
> Components: IDE
> Affects Versions: Sling Eclipse IDE 1.0.10
> Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an
> exception while updating rendition files. This seems to be caused by the DAM
> Workflows inside AEM which is triggered as soon as the original file is
> updated. This is probably due to the fact that the "impl-vlt" code is
> committing a change after each and every command and so the workflow is
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so
> that a logical group like a DAM asset can be update in single step.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
