# Synchronizing signal method executions

**URL:** <https://community.temporal.io/t/synchronizing-signal-method-executions/642>\
**Category:** Community Support\
**Tags:** java-sdk\
**Created:** [September 17, 2020, 7:03pm UTC](https://community.temporal.io/t/synchronizing-signal-method-executions/642 "2020-09-17T19:03:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![m\_p](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/m_p/32/161_2.png) [@m\_p](https://community.temporal.io/u/m_p)\
**Post date:** [September 17, 2020, 7:03pm UTC](https://community.temporal.io/t/synchronizing-signal-method-executions/642/1 "2020-09-17T19:03:34Z")

</div>

Hello,  
I’d like to ask if there is a way / pattern of synchronizing signal method invocations.

In our use case, REST controller handles user responses. These are then signalled to a running workflow.

The issue is when a signalmethod would modify how the next signalmethod invocation should be handled (imagine only the first response is accepted, but the response has to be verified against external api called via activity).

For example:

1. `acceptSignal` is handled, invoking `someActivityMethod` -\> scheduling `someActivityTask1`
2. another `acceptSignal` is handled -\> scheduling `someActivityTask2`.
3. `someActivityTask1` starts and completes (calling external api and modifying workflow state)
4. `someActivityTask2` starts and completes (calling external api…)

We would ideally want to wait for `someActivityTask1` (and any other tasks scheduled in the signal method) to finish before entering the `@SignalMethod` again, calling the `someActivityMethod` and scheduling `someActivityTask2`.

Is this a valid case?  
Should we somehow utilize the `WorkflowQueue` or is there a different pattern for accomplishing this with workflows only, without utilizing some external synchronization?

Thank you

edit: I feel like I might be asking similar thing to what has been answered here: [Limit workflow-based concurrent executions?](https://community.temporal.io/t/limit-workflow-based-concurrent-executions/633/4) so I will explore the linked repository, although I am already signalling this workflow so this is where I would like to buffer the activity executions.

---

<div class="post-metadata">

**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\
**Post date:** [September 18, 2020, 3:23am UTC](https://community.temporal.io/t/synchronizing-signal-method-executions/642/3 "2020-09-18T03:23:55Z")

</div>

You cannot delay @SignalMethod invocation. So for your use case buffering the signal data in the workflow field of `WorkflowQueue` type is the best option. I filed [an issue](https://github.com/temporalio/java-sdk/issues/214) to make the threading of the signal handling method configurable.

---

<div class="post-metadata">

**Author:** ![m\_p](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/m_p/32/161_2.png) [@m\_p](https://community.temporal.io/u/m_p)\
**Post date:** [September 18, 2020, 7:09am UTC](https://community.temporal.io/t/synchronizing-signal-method-executions/642/4 "2020-09-18T07:09:31Z")

</div>

Thank you for the answer (and for filing the feature issue).  
We will try implementing the signal handling using the `WorkflowQueue` for now.

I don’t feel confident submitting changes to the documentation as I clearly don’t understand the internals very well but in this case, the section about [workflow constraints](https://docs.temporal.io/docs/java-implementing-workflows#workflow-implementation-constraints)

> Don’t use any synchronization, locks, and other standard Java blocking concurrency-related classes besides those provided by the Workflow class. There is no need in explicit synchronization because multi-threaded code inside a workflow is executed one thread at a time and under a global lock.

was probably the primary source of our confusion when it comes to how the threading works with signals.