If I create a new instance of a process, and then immediately come back and query for that process, should I expect that the process has been created in the DB and that (assuming my query is correct and that the process has not completed) the process will always be returned?
We are seeing intermittent issues where this fails for us, i.e. we create an instance of our process, then immediately query for it and get nothing back. It’s not reliably reproducible, unfortunately. Just wondering if we should be assuming that there is transactional consistency around process creation calls.
If you create it from within a Service Tasks then you won’t be able to query it (with the ProcessInstanceQuery) immediately. However, there is a way to get the ProcessIntance by id (but not with the public API). What exactly are you trying to achieve? When starting the process you get the ProcessInstance back
The reason for not being able to query is that when running within a CommandContext the entities are flushed to the database after the context is closed. When you are doing it from within a service task, or in a chain of service tasks then you are still in the same Command Context.
In this case you can do something like CommandContextUtil.getExecutionEntityManager().findById(id). This will work because there is cache from which the entity would be fetched.
This is really a problem. I have common functionality built around the API. I now have to drop that API client in favour of using the Utils to include the cache. How can this be considered correct?
I’m not sure what you’re referring to? The caching has always been there on entityManager level. The API hasn’t changed in years. Can you elaborate what you mean? Or create a new post (as it might confuse the original author suddenly receiving emails on a two-year old topic).
I think this ties in perfectly with the original query.
If i have some shared functionality querying the db through the API, i don’t find the Execution i just started. Once it hits the first UserTask it is available through the API, but before that it’s not.
I had to change the usage of the API to prefer the CommandContextUtils so that i can access the data in the cache:
From the RuntimeService a ProcessInstance is returned.
To get the vars from there you would need processInstance.getProcessVariables().
From CommandContextUtil you need ((ExecutionEntityImpl) processInstance).getVariables() to get hold of them.
And never the 2 meet? Even though they are both (instanceof ExecutionEntityImpl) at runtime. Maybe i’m just totally off track here?
If i create a ProcessInstanceQueryImpl and use that for the query: CommandContextUtil.getExecutionEntityManager().findProcessInstanceAndVariablesByQueryCriteria(processInstanceQuery);
I get the same result - no cache results because of enableEagerExecutionTreeFetching brought into consideration.
What i don’t get is that in both cases the variables are available but not through the same methods.
On ExecutionEntityImpl that is cast to ProcessInstance i get "lazy loading outside command context" on processInstance.getProcessVariables(), but as soon as i cast it back to ExecutionEntityImpl i get them on ((ExecutionEntityImpl) processInstance).getVariables();