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; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Flushing process instance attachments to database within tx

wsalembi

Process instance attachments created in one Service Task are not visible in the following Service Task, because apparently they are only flushed to the database at the end of a transaction. Is this the desired behavior?

Is there any way to force a flush? The attachments don't need to be committed but a flush before query seems appropriate if the following tasks want a consistent view of the attachments created?

My current workaround is to define the next Service Task asynchrounous to force the tx commit. But this is not my intended behavior.

Find more posts tagged with

Comments

frederikherema1

Activiti doesn't flush anything to the database unless it encounters a wait-state, async step or process-end. This is intended behavior. So if a user-task is reached, all data is flushed. When you start a new process-instance from within another process, the transaction is reused and indeed the new process in only flushed when the spawning process is committed.

Doing API-calls from inside a running process (eg. from a service-task) is allowed but needs to be handled with care and the flushing-behaviour should be kept in mind. I'm afraid there is no other way that making the activity that needs the data async to force a flush…

wsalembi

- Why is the behavior of attachments different then process variables? They both live in memory and are flushed at the end of the transaction. Still, process variables can be updated in sequential service tasks. Would it be feasible to make attachments available via the DelegateExecution object?
- Another solution is to use an external file storage and pass the attachment reference using process variables.

jbarrez

- it would be possible, but what is the added value? Why not use a variable from the start then?

- Yes, that is the way it is implemented eg in Alfresco.

wsalembi

I see lots of advantages. First, leverage the existing attachment feature in activiti. Everything is in the activiti database. No need for external storage. It is easier to share the documents to multiple process engine instances.

Using attachments I can visualize them in Activiti Explorer. Not possible with process variables.

I suppose attachments are more efficient, then byte array process variables, which can take a lot of memory when the files tend to get large.

I think I'll use a local file storage for sequential service tasks and end by an additional service task that persists the attachment before any user task.

jbarrez

The attachments are actually mapped to the byte array table … so there is benefit of using it over a variable.

Generally, I would not advise to store documents and all the Activiti database tables. There are systems out there which are optimized for such things, and which offer other capabiolities on top (full text search, OCR, etc…). What we do for example in Alfresco, is we just store the node reference (a string) to the actual document and fetch it when we actually need kt.