nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

RuntimeService getVariable flushes

mystarrocks

Hi,

Calling org.activiti.engine.RuntimeService.getVariable causes the corresponding ByteArrayEntity content to be updated and flushed when it is supposed to only be read. Because we are attempting to read the process (and its variables) in multiple transactions, this causes an ActivitiOptimisticLockingException, when in reality, there's nothing we are trying to update, but just access the variable and the data in the ACT_GE_BYTEARRAY for the variable.

Marking it read-only doesn't seem to help - the below doesn't affect the update in any way:

@Transactional (readOnly = true, propagation = Propagation.REQUIRES_NEW)

public Object getRuntimeVariable(String processInstanceId, String name) {
return runtimeService.getVariable(processInstanceId, name);
}

Is there anyway to prevent the flushing from happening in case of reading a variable like this? If not, can we restrict the flushing only to when there's actually a change in data? The data in this variable is a serialized Java object, so would making sure the properties haven't changed be enough to prevent the flushing?

I am on Activiti version 5.13.

Find more posts tagged with

Alfresco Process Services

Accepted answers

ryandawson

It seems like this is the same problem as runtimeService.getVariables requires a ReadW and there it was suggested that the key problem is that the read for deserialization of a java object is not a normal read. Perhaps you could check this by testing without the java objects (maybe you could even work around). It would be great if you could also check whether it affects v6.

All comments

ryandawson

mystarrocks

Yes, it is related, and yes, it does work in cases where the data isn't a serialized Java object. It was and is still unclear how the serialization affects the detection of changes (assuming changes are committed/flushed only if there was a change to the contents, that is), but assuming it does affect, is there any way to prevent such superfluous updates from the application side?

We have plans to upgrade to 6 soon, so it would be great if this were to work correctly on v6 (I doubt it - I see the relevant part of the code hasn't changed; maybe I am wrong), but I am afraid I won't be able to test this on v6 yet.

ryandawson

I guess the next natural question is whether this is an Activiti bug or a limitation of the feature to serialize a java object in a variable. If you have any thoughts on what could be different about the Activiti implementation in order to avoid the problem that would be great. It may be that raising an issue in GitHub is the best path and if so the more detail that can go in the issue the better.

mystarrocks

I must admit I haven't looked deeply into what's causing this -- I was referring to the method in this thread to suggest this may not be fixed in the recent versions either.

We've decided to handle (catch/retry) the ActivitiOptimisticLockingException due to simultaneous reads (-turned-writes) of such variables for the time being, and we have plans to completely stop storing data in the serialized form going forward.