AEM反向复制与后续工作流：竞态条件规避技术问询

看起来你已经把核心流程跑通了——从Publisher上传反向同步到Author，再正向推到另一个Publisher，还通过自定义启动器触发工作流完成项目创建、资产迁移和清理，很棒！现在要解决竞态条件，本质上就是要确保反向复制的资产完全落地到Author后，再执行后续的项目创建和迁移操作，下面给你几个实操性强的方案：

1. 替换自定义启动器，改用反向复制完成事件触发 #

自定义启动器的触发时机可能早于反向复制的节点持久化（比如还在JCR的会话提交阶段），这时候去操作资产肯定会出问题。建议换成监听AEM的ReplicationAction.EVENT_TOPIC事件，精准捕捉反向复制成功完成的信号：

• 监听事件时，先判断事件类型是ReplicationActionType.REVERSE_REPLICATE，且复制状态为SUCCESS
• 不要在事件线程里直接执行工作流，而是通过JobManager提交异步任务——这样既不会阻塞事件处理，还能让JCR有足够时间完成节点的持久化

给你一段核心代码示例：

@Component(immediate = true)
@Service(EventHandler.class)
@Property(name = EventConstants.EVENT_TOPIC, value = ReplicationAction.EVENT_TOPIC)
public class ReverseReplicationCompletionHandler implements EventHandler {

    @Reference
    private JobManager jobManager;

    @Override
    public void handleEvent(Event event) {
        ReplicationAction action = ReplicationAction.fromEvent(event);
        // 过滤反向复制成功的事件
        if (ReplicationActionType.REVERSE_REPLICATE.equals(action.getType()) 
            && ReplicationStatus.Status.SUCCESS.equals(event.getProperty(ReplicationStatus.STATUS))) {
            
            String assetPath = action.getPath();
            // 提交异步处理任务
            Map<String, Object> jobProps = new HashMap<>();
            jobProps.put("targetAssetPath", assetPath);
            jobManager.addJob("your-app/jobs/process-replicated-asset", jobProps);
        }
    }
}

2. 在工作流中增加资产就绪校验+重试机制 #

就算用了事件触发，也可能因为JCR的会话延迟导致资产节点还没完全就绪。在工作流的资产迁移步骤前，加一层校验逻辑：

• 检查资产节点是否存在，且关键子节点（比如jcr:content）是否已加载
• 如果未就绪，短暂休眠后重试几次（比如重试3次，每次间隔1秒），避免直接失败

示例代码片段：

private boolean isAssetReady(ResourceResolver resolver, String assetPath) {
    Resource assetRes = resolver.getResource(assetPath);
    if (assetRes == null) return false;
    // 校验关键子节点是否存在
    return assetRes.getChild("jcr:content") != null;
}

// 在工作流执行前调用
private boolean waitForAsset(ResourceResolver resolver, String assetPath) throws InterruptedException {
    int retryCount = 0;
    final int MAX_RETRIES = 3;
    final long RETRY_DELAY = 1000; // 1秒
    
    while (retryCount < MAX_RETRIES) {
        if (isAssetReady(resolver, assetPath)) {
            return true;
        }
        retryCount++;
        Thread.sleep(RETRY_DELAY);
        resolver.refresh(); // 刷新资源解析器，获取最新节点状态
    }
    return false;
}

3. 用JCR锁机制防止并发操作 #

如果存在多个反向复制请求同时触发工作流的情况，对目标资产和项目路径加锁能避免并发修改：

• 在处理资产前，通过Node.lock()获取排他锁
• 操作完成后调用Node.unlock()释放锁
• 注意要在try-finally块中处理锁，避免异常导致锁无法释放

示例：

Node assetNode = resolver.getResource(assetPath).adaptTo(Node.class);
try {
    assetNode.lock(true, false); // 排他锁，不允许其他会话读取
    // 执行项目创建、资产迁移逻辑
} finally {
    if (assetNode.isLocked()) {
        assetNode.unlock();
    }
}

4. 依赖反向复制的回调接口（进阶方案） #

如果是通过代码触发反向复制，可以注册ReplicationListener，在onReplicationComplete回调中直接触发工作流——这种方式能最精准地把控复制完成的时机，从根源上消除竞态：

ReplicationOptions options = new ReplicationOptions();
options.setListener(new ReplicationListener() {
    @Override
    public void onReplicationComplete(ReplicationAction action, ReplicationResult result) {
        if (result.isSuccess() && ReplicationActionType.REVERSE_REPLICATE.equals(action.getType())) {
            // 触发项目创建与资产迁移工作流
            WorkflowSession wfSession = ...;
            WorkflowModel model = wfSession.getModel("/etc/workflow/models/your-model");
            Map<String, Object> payload = new HashMap<>();
            payload.put("assetPath", action.getPath());
            wfSession.startWorkflow(model, payload);
        }
    }
    
    // 实现其他接口方法
});
// 执行反向复制
replicator.replicate(resolver, ReplicationActionType.REVERSE_REPLICATE, assetPath, options);

把这些方案组合起来用，基本就能彻底解决竞态问题了——先通过事件/回调确保复制完成，再校验资产就绪，最后加锁防止并发，层层保障。

内容的提问来源于stack exchange，提问作者Karthik