Error when using workflow Fork with Condition that immediately was executeError when using workflow Fork with Condition that immediately was executehttps://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=1183567912024-03-28T20:16:25Z2024-03-28T20:16:25ZRE: Error when using workflow Fork with Condition that immediately was exeali yeganehhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1184086872020-02-03T10:01:07Z2020-02-03T10:01:07ZHi David H Nebinger<br /> I tried the workflow xml file in liferay 6.2 and 7.3 which worked correctly (attached file) <br /><strong>I think this problem was a bug in liferay 7.2 and fixed in 7.3.</strong><br /><strong></strong>ali yeganeh2020-02-03T10:01:07ZRE: Error when using workflow Fork with Condition that immediately was exeDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183879662020-01-30T20:10:58Z2020-01-30T20:10:58ZGet rid of the stubs and build out your whole workflow.<br /><br />If it still fails with real code, then come back and share. This stub that you're using is not realistic enough.David H Nebinger2020-01-30T20:10:58ZRE: Error when using workflow Fork with Condition that immediately was exeali yeganehhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183876192020-01-30T19:11:37Z2020-01-30T19:11:37ZUsing Thread.sleep() is a safe code?<br />Is it possible to run two threads simultaneously.<br />I think fork and condition should manage this, for example, giving priority to threads.<br /><strong>Is there a solution to this problem?</strong>ali yeganeh2020-01-30T19:11:37ZRE: Error when using workflow Fork with Condition that immediately was exeDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183835622020-01-30T14:10:40Z2020-01-30T14:10:40ZI feel it is because of the speed at which both get evaluated. Since there is no code in the condition path, those two actions are happening simultaneously and they end up stepping on each other as a result.<br /><br />I think if you added a Thread.sleep() call before the return, wait for like 250ms or something (simulating the condition checking something before returning a result), your issue would likely resolve itself since the simultaneous update on two paths would fall away.<br /><br />While it looks like a race condition, it certainly is not solvable using a synchronized keyword because there are no methods being declared or invoked here.David H Nebinger2020-01-30T14:10:40ZRE: Error when using workflow Fork with Condition that immediately was exeali yeganehhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183764592020-01-30T09:53:51Z2020-01-30T09:53:51Z<div class="quote-title">David H Nebinger:</div><blockquote><br />So most of the time this message indicates that two pieces of code have retrieved the same entity, one made a change and persisted it, the second one made its own change and is trying to store it; basically it is holding a stale object that was modified by something else.<br /><br />The solution is typically a fetch-then-update so you can eliminate the possibility of a stale object.<br /><br />In your particular case, I think you're just suffering from the lack of any real logic built into your flow. There's nothing stopping or pausing as an entity goes through the workflow. And since everything is happening at once, you're seeing these kinds of simultaneous updates stepping on each other.<br /></blockquote>Hi<br />This exception occurs when I add <em>returnvalue </em> script to the condition, according to attache file.<br /><strong>Is it possible in fork or condition nodes to holding a stale object that was modified by something else?</strong>ali yeganeh2020-01-30T09:53:51ZRE: Error when using workflow Fork with Condition that immediately was exeDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183657542020-01-28T23:49:42Z2020-01-28T23:49:42Z<div class="quote-title">ali yeganeh:</div><blockquote><br />According to your description , this is a problem that occurs in a multi-thread environment ( <strong>Race condition </strong> ) which is solved by synchronized keyword .</blockquote><br /><br />What? I didn't say anything about threads or race conditions and synchronized keywords; synchronized wouldn't fix anything with the error the OP is reporting.David H Nebinger2020-01-28T23:49:42ZRE: Error when using workflow Fork with Condition that immediately was exeVahid Khhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183630872020-01-28T20:55:29Z2020-01-28T20:55:29ZIn my scenario, some of Reviews must be ignored so Conditions must go through join immediately. And because sometimes multiple conditions execute in one time it make error.How can I manage conditions that will run respectively?Vahid Kh2020-01-28T20:55:29ZRE: Error when using workflow Fork with Condition that immediately was exeali yeganehhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183610692020-01-28T18:24:25Z2020-01-28T18:24:25Z<html><head></head><body><div class="quote-title">David H Nebinger:</div><blockquote><br>So most of the time this message indicates that two pieces of code have retrieved the same entity, one made a change and persisted it, the second one made its own change and is trying to store it; basically it is holding a stale object that was modified by something else.<br><br>The solution is typically a fetch-then-update so you can eliminate the possibility of a stale object.<br><br>In your particular case, I think you're just suffering from the lack of any real logic built into your flow. There's nothing stopping or pausing as an entity goes through the workflow. And since everything is happening at once, you're seeing these kinds of simultaneous updates stepping on each other.<br></blockquote><br>Hi David<br>I have this problem too.<br>According to your description , this is a problem that occurs in a multi-thread environment ( <strong>Race condition </strong> ) which is solved by synchronized keyword .<br>What is the solution when I need multiple tasks running concurrently, according to the that I do not know how the shared object is updated ?<br>According to the attachment file , I created 2 conditions and in the script wrote <br> <pre><code>returnValue = "MyTransition" ;</code></pre><br>This script is the cause of the exception.</body></html>ali yeganeh2020-01-28T18:24:25ZRE: Error when using workflow Fork with Condition that immediately was exeDavid H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183589972020-01-28T16:10:32Z2020-01-28T16:10:32ZSo most of the time this message indicates that two pieces of code have retrieved the same entity, one made a change and persisted it, the second one made its own change and is trying to store it; basically it is holding a stale object that was modified by something else.<br /><br />The solution is typically a fetch-then-update so you can eliminate the possibility of a stale object.<br /><br />In your particular case, I think you're just suffering from the lack of any real logic built into your flow. There's nothing stopping or pausing as an entity goes through the workflow. And since everything is happening at once, you're seeing these kinds of simultaneous updates stepping on each other.David H Nebinger2020-01-28T16:10:32ZError when using workflow Fork with Condition that immediately was executeVahid Khhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1183567902020-01-28T12:26:04Z2020-01-28T12:26:04Z<html><head></head><body>Hello <br>When I using Fork/Join with Condition that immediately was executed afterwards the below exception occured:<br><br><pre><code>ERROR [liferay/kaleo_graph_walker-105][ParallelDestination:59] Unable to process message {destinationName=liferay/kaleo_graph_walker, response=null, responseDestinationName=null, responseId=null, payload=com.liferay.portal.workflow.kaleo.runtime.graph.PathElement@1172d069, values={defaultLocale=fa_IR, companyId=20101, groupId=0, principalName=20130, permissionChecker=com.liferay.portal.kernel.util.TransientValue@245cf11b, siteDefaultLocale=fa_IR, themeDisplayLocale=en_US}}
com.liferay.portal.kernel.messaging.MessageListenerException: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.liferay.portal.workflow.kaleo.model.impl.KaleoInstanceImpl#58884]
at com.liferay.portal.kernel.messaging.BaseMessageListener.receive(BaseMessageListener.java:32)
at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:74)
at com.liferay.portal.messaging.internal.ParallelDestination$1.run(ParallelDestination.java:56)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:752)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:664)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.liferay.portal.workflow.kaleo.model.impl.KaleoInstanceImpl#58884]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1950)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2595)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2495)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2822)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at com.liferay.portal.dao.orm.hibernate.event.NestableFlushEventListener.onFlush(NestableFlushEventListener.java:61)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at com.liferay.portal.spring.hibernate.PortletTransactionManager$TransactionStatusWrapper.reset(PortletTransactionManager.java:260)
at com.liferay.portal.spring.hibernate.PortletTransactionManager.commit(PortletTransactionManager.java:63)
at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.commit(DefaultTransactionExecutor.java:41)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:77)
at com.liferay.portal.spring.aop.AopMethodInvocationImpl.proceed(AopMethodInvocationImpl.java:57)
at com.liferay.portal.service.ServiceContextAdvice.invoke(ServiceContextAdvice.java:60)
at com.liferay.portal.spring.aop.AopMethodInvocationImpl.proceed(AopMethodInvocationImpl.java:57)
at com.liferay.portal.spring.aop.AopInvocationHandler.invoke(AopInvocationHandler.java:49)
at com.sun.proxy.$Proxy698.updateKaleoInstance(Unknown Source)
at com.liferay.portal.workflow.kaleo.runtime.internal.node.ConditionNodeExecutor.doExecute(ConditionNodeExecutor.java:68)
at com.liferay.portal.workflow.kaleo.runtime.node.BaseNodeExecutor.execute(BaseNodeExecutor.java:83)
at com.liferay.portal.workflow.kaleo.runtime.internal.graph.DefaultGraphWalker.follow(DefaultGraphWalker.java:74)
at sun.reflect.GeneratedMethodAccessor544.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.liferay.portal.spring.aop.AopMethodInvocationImpl.proceed(AopMethodInvocationImpl.java:50)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:69)
at com.liferay.portal.spring.aop.AopMethodInvocationImpl.p