Service call or not, the update is still happening in the same transaction at the same point in the flow. I'd strongly suggest you keep trying your load tests as I really can't see how anything has changed significantly.
Regards Scott On 30/10/2014, at 8:40 pm, Jacques Le Roux <[email protected]> wrote: > I tend to agree, that's why I simply bypassed the service call. Since the > ProductCalculatedInfo is only for recording matter a call after could be a > better solution. For now, I tried to change things as less as possible. > > Jacques > > Le 30/10/2014 07:35, Scott Gray a écrit : >> I have serious doubts there's any significant performance problems with this >> simple method. Given this problem occurred during load testing I would be >> almost certain that the problem is lock contention on the >> ProductCalculatedInfo records. >> >> It's the same old story: >> - Long running order creation transaction >> - Updating a record that will be touched by many order creation >> transactions, causing a lock on the record until the transaction is committed >> - The transactions queue up, eventually they have to wait too long and the >> lock wait timer runs out or the transaction timeout is hit >> >> The service should be executed in separate transaction after the order >> submission transaction is committed. >> >> Regards >> Scott >> On 30/10/2014, at 7:23 pm, Adrian Crum <[email protected]> >> wrote: >> >>> Thanks Jacopo. >>> >>> I noticed the Mini-language service uses two deprecated elements: >>> >>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+%28minilang%29+Reference >>> >>> <calculate> should be replaced with <set> and <call-class-method> should be >>> replaced with <script>. >>> >>> Perhaps if that service was updated performance would improve. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 10/30/2014 5:57 AM, Jacopo Cappellato wrote: >>>> On Oct 29, 2014, at 8:24 PM, Jacques Le Roux >>>> <[email protected]> wrote: >>>> >>>>> Apart what I reported in the commit comment and the Jira description, I >>>>> did not make other measures. Before it was blocking the JMeter test after >>>>> it passed. >>>> I suspect that the main difference could be Minilang vs Java, not between >>>> service vs method call: this is why I think it would be interesting to >>>> test the latter (java service vs java method). >>>> We should not switch to direct Java method calls so lightly, at least not >>>> before trying our best to find the root causes (in the service call chain) >>>> of the low performance. >>>> This effort would (if we find the bottleneck in the service call and >>>> manage to fix it) improve the whole system in one shot rather just fixing >>>> one service. >>>> Even if the difference is Minilang vs Java, it may be interesting to try >>>> to figure out what is the reason for it (I suspect it could be the larger >>>> number of reflexion) and try to fix it. >>>> I am willing to help you in these tasks but in the meantime I would change >>>> you latest code to use a service call (to Java) rather than a direct >>>> method call, mostly for consistency with the rest of the codebase. >>>> >>>> Kind regards, >>>> >>>> Jacopo >>>> >> >>
