Have some questions on Workflows & Activities
I understand that in a workflow, all variables and threads are stored/persisted and activities encapsulate external unreliable services.
Should all workflow variables be Serializable? What kind of serialization is used here?
Does Temporal persist the input and output of an Activity as well?
Is thread persistence achieved through variable persistence and rebuilding the state using event sourcing?
In a decision step between two activities, if the decision is made on an external state, should that call also be encapsulated in an activity?
Should all workflow variables be Serializable? What kind of serialization is used here?
Workflow variables are not required to be serializable as workflow state is rebuilt in the case of failure by replaying events in the workflow execution history (event sourcing). But if you use a workflow variable as input to an activity or return it in response to query handler, then it needs to be serializable.
Does Temporal persist the input and output of an Activity as well?
Yes. All activity input parameters are serialized and stored within ActivityScheduledEvent in execution history.
Is thread persistence achieved through variable persistence and rebuilding the state using event sourcing?
I’m not sure I fully understand the question. The only restriction Temporal puts on workflow logic is, that it needs to be deterministic. Temporal SDK also has a scheduler which executes multi-threaded code in deterministic manner. In the case of failure we replay your workflow code using execution history and considering it is deterministic we end up exact same state along with all threads, local variables and call-stack.
In a decision step between two activities, if the decision is made on an external state, should that call also be encapsulated in an activity?
Anything which pulls in state from external source needs to be called within Activity or LocalActivity.
In one of the previous discussions, it was mentioned that when the system is loaded threads could be removed to make resources available for other executions. When a removed thread comes back into action, I guess the states are replayed to continue the execution.
Lets say I make a rest callA. Based on its return value, I would like to decide between callB and callC. I guess all calls needs to be wrapped inside an activity to make it deterministic.
The calls to A, B and C have to be inside the activities. The logic that decides which activity to call based on data should reside inside the workflow.
Let’s say during the first run the rest call returns status “a”, then somewhere on the next lines the worker dies and the workflow will be replayed. This time, the rest call would return status “b” if it was called, but my understanding is that return status “a” from
the previous call is persisted and the rest call will not be made again. So the replay actually happens with an old (stale) state.
Came across this topic while looking for information around the thread persistence. Just to make sure I understand, when we refer to thread persistence, we are referring to the replay of the workflow code using the event sourcing to arrive at the same state of the execution thread ? Or is the thread state serialized and persisted ?
Thanks !
Hii @maxim, Just wanted a clarification on local variables. I have a local variable in my workflow which is used to decide whether workflow is cancelled or not. My service is exposing an api and that api takes workflowId as input and retrieves the workflow and then access that local variable to change it’s value to “cancelled”. As this is happening on multi-thread, I just want to know how the local variable of a workflow is stored at temporal. Also, if this approach is correct or not??(This is also what described in Temporal subscription samples).
My service is exposing an api and that api takes workflowId as input and retrieves the workflow and then access that local variable to change it’s value to “cancelled”.
Would you explain how exactly the
change it’s value to “cancelled”
is implemented?
The supported way to change such a variable is to send a signal to the workflow and update the variable from the signal handler.
Yes @maxim I am sending signal only to update the variable value and the value is updated in the implementation of signal method of workflow interface.
I believe what’s meant is if you use a variable defined in your workflow code as input to activity / child workflow invocations, or return it from a query handler method it has to be serializable, for example (java sdk):
public class MyWorkflowImpl implements MyWorkflowInterface {
private MyObject myObject = ...;
// Workflow method
@Override
public void myWorkflowMethod() {
// ...
activities.doSometing(myObject);
}
// Query Method
@Override
public MyObject queryMyObject() {
return myObject;
}
// ...
}
In this case MyObject has to be serializable by either the default data converters or a custom one that you specify.