Or as an alternative it could be run in the same transaction right before committing, to reduce the amount of time the lock is held.
Regards Scott On 30/10/2014, at 7:35 pm, Scott Gray <[email protected]> wrote: > 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 >>> >
