Sub-Flow с повторным использованием и параллелизмом

Question

Я работаю над подготовкой решения для одного из моих случаев. Мое решение - это то, что может выглядеть так абстрактно.

Мой вопрос здесь заключается в том, что, когда два основных потока одновременно вызывают один и тот же подпоток, он будет работать без каких-либо проблем?

Также мне нужно написать код как потокобезопасный для всех классов, которые используются в качестве пользовательских компонентов / trnasformers в подпотоке?

Моя абстрактная конфигурация выглядит так, как указано ниже.

<flow name="mainflow_1" >
    <inbound-endpoint/>
    <transformer ....>
    <component ....>
        <flow-ref name="subflow_1"></flow-ref>
    <transformer ....>
    <component  ...>
    <outbound-endpoint ....>
</flow>

<flow name="mainflow_2" >
    <inbound-endpoint  type="request-response" />
    <transformer ....>
    <component ....>
        <flow-ref name="subflow_1"></flow-ref>
    <transformer ....>
    <component  ...>            
</flow>

<sub-flow name="subflow_1" >        
    <transformer ....>
    <component ....>
        <outbound-endpoint  call to some service >
    <transformer ....>
    <component  ...>        
</sub-flow>

Пожалуйста, ведите меня.

Answer 1

Подпоток действует как макрос: с точки зрения исполнения, как если бы элементы подпотока были скопированы в вызывающий поток.

Таким образом, именно поведение потоков вызывающего потока будет определять поведение потоков подпотока.

Независимо от того, используются ли они в подпотоках или основных потоках, вы должны написать классы компонентов для обеспечения безопасности потоков, если вы используете их единичные экземпляры (общий вариант использования). Если вы используете экземпляры прототипов (один экземпляр создается для каждого запроса) или объединенные экземпляры (ограниченное количество экземпляров, узкие места в потоках), классы компонентов могут быть небезопасными для потоков.

Как правило, старайтесь создавать поточно-ориентированные классы компонентов без сохранения состояния настолько, насколько это возможно, чтобы избежать потенциальных проблем с оптимизацией в будущем.