I have a process where there are several required form properties, and when creating the process instance I also set a variable which happens to be a Map. This seems to work fine, I see the variable show up in ACT_RU_VARIABLE as a serialized variable and the serialized value is in ACT_GE_BYTEARRAY.
However, I have a subsequent service task where I want to map my variable “record” to a field also named “record”, this is the extension element:
Upon doing more testing, sometimes it works, others it doesn’t. I discovered this by debugging it and then things started working, so I added some logging and just ran it normally and it seems there is a timing issue or race condition and sometimes it will fail on first try but when it retries it succeeds.
The process is extremely simple, Start --> Service Task --> End, so is there something perhaps asynchronous that is persisting the serializable variable that isn’t complete yet when the Service Task executes, but ends up being done on one of the retries and so succeeds?
To further confirm my suspicion, I added a timer event before the service task and with that delay introduced, I have not seen a failure.
The next question is, assuming this is right and serialized variables aren’t necessarily fully persisted before the next step in a process is performed, can this happen anywhere or is it unique to the first step after a start event?
Also, I know I’m using an old version, so is this issue present in the latest release? Is there a solution for my version other than introducing an artificial delay?
Good analysis. Serialized variables are indeed not fully persisted until the end of the transaction. They are marked as ‘changed’ and only evaluated at the end, for not impacting performance as serialization is quite heavy. So to be honest, I’m surprised it worked sometimes.
Not for serialized variables. Regular variables (the ones not stored as bytes) will work properly as they don’t have this delay.
I may have been fiddling with making some steps (a)synchronous and/or it was the step being retried that made it work in some cases.
But if the variable is marked as ‘changed’ it is in memory then, is there any way to access it rather than the variable retrieval hitting the database where the variable has not yet been persisted?
So is this a bug? Or this is by design? Certainly seems like a bug to me so should an issue be opened?
And given your description, until the bug is fixed, it seems like the only workaround is to introduce a step in the process to complete the transaction so it gets persisted, is that accurate? A timer works, but is there a better technique to accomplish this that doesn’t introduce a delay? I set a timer for 1 second but the default executor appears to be set to check every 10 seconds so that is a longish delay much of the time. I have changed the executor check period to 1 second, but I assume that has drawbacks of it checking a whole lot more often.