Transactional blocks within scheduled task

Any issue about Cyclos 4 scripting and Webservices

Moderators: hugo, alexandre, rmvanarkel

Post Reply
jjubi
Posts: 1
Joined: Tue Dec 10, 2019 2:09 pm

Transactional blocks within scheduled task

Post by jjubi »

Hi,

I'm using cyclos 4.11.4 and I would like to run different actions from within a scheduled task, so I tried to run each of these actions inside a transactional commit listener. However, I've found out that queries behave differently within the commit listener and sometimes return empty sets or fail with some cyclos exception. This is a simple example to reproduce one of the problems (just replace both occurrences of "myusername" with whichever user is present in your Cyclos instance):

Code: Select all

import org.cyclos.model.users.users.UserLocatorVO
println "[TEST_BUG] Running scheduled task..."
def admin1 = userLocatorHandler.locate(
        new UserLocatorVO([principal: 'myusername'])
    ).user
println "[TEST_BUG] Found user 1: ${admin1}"
scriptHelper.addOnCommitTransactional {
def admin2 = userLocatorHandler.locate(
        new UserLocatorVO([principal: 'myusername'])
    ).user
    println "[TEST_BUG] Found user 2: ${admin2}"
}
println "[TEST_BUG] Finished scheduled task (on commit handlers may still have to run)."
return "End of test"
This is the output and error that occurs when the previous script is run as a scheduled task (however, it works fine when run through the "run script" page in Cyclos, so it must have something to do with having an active user session):

Code: Select all

[TEST_BUG] Running scheduled task...
[TEST_BUG] Found user 1: User#12: My User Name
[TEST_BUG] Finished scheduled task (on commit handlers may still have to run).
15:00:02,424  WARN InvocationContext - Error while running commit listener
org.cyclos.model.users.users.LocateUserException: User, key=myusername
        at org.cyclos.impl.users.UserLocatorHandlerImpl.throwNotFoundException(UserLocatorHandlerImpl.java:673)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.doLocateByPrincipal(UserLocatorHandlerImpl.java:564)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.performLocate(UserLocatorHandlerImpl.java:656)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.lambda$0(UserLocatorHandlerImpl.java:204)
        at org.cyclos.impl.InvocationContext.getAttribute(InvocationContext.java:661)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.doLocate(UserLocatorHandlerImpl.java:203)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.locate(UserLocatorHandlerImpl.java:158)
        at org.cyclos.impl.users.UserLocatorHandlerImpl.locate(UserLocatorHandlerImpl.java:147)
        at org.cyclos.impl.users.UserLocatorHandler$locate.call(Unknown Source)
        at Script6$_run_closure1.doCall(Script6.groovy:14)
        at Script6$_run_closure1.doCall(Script6.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
        at groovy.lang.Closure.call(Closure.java:418)
        at groovy.lang.Closure.call(Closure.java:412)
        at groovy.lang.Closure.run(Closure.java:499)
        at org.cyclos.impl.InvocationContext$1.doInTransactionWithoutResult(InvocationContext.java:839)
        at org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:36)
        at org.cyclos.impl.utils.transaction.TransactionHandlerImpl.runEnsuringInvocationContext(TransactionHandlerImpl.java:183)
        at org.cyclos.impl.utils.transaction.TransactionHandlerImpl.doRun(TransactionHandlerImpl.java:109)
        at org.cyclos.impl.utils.transaction.TransactionHandlerImpl.run(TransactionHandlerImpl.java:159)
        at org.cyclos.impl.utils.transaction.TransactionHandlerImpl.run(TransactionHandlerImpl.java:80)
        at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:206)
        at com.sun.proxy.$Proxy20.run(Unknown Source)
        at org.cyclos.impl.InvokerHandlerImpl.performInTransaction(InvokerHandlerImpl.java:238)
        at org.cyclos.impl.InvokerHandlerImpl.doRunAsInTransaction(InvokerHandlerImpl.java:187)
        at org.cyclos.impl.InvokerHandlerImpl.runAsInTransaction(InvokerHandlerImpl.java:168)
So:
  • How can I prevent this unexpected behaviour?
    Is there an alternative safe way to split the task into several transactional blocks?
Post Reply