I have confirmed the above suspicion. By adding a context.close() call before I go to
sleep, the job is flushed to the database and the JobExecutorThread can update it without
the Lock wait timeout exception.
Is this a bug or an accepted workaround?
I would expect that when I close the context in my unit test, I will now have to reopen it
again to lookup a process definition or other such tasks. I feel that the engine should
take care of properly commiting as necessary. I can see why commits may want to be
deferred for performance reasons, but that strategy falls apart when there are other
threads of execution (ala JobExecutor, custom web service, etc.) that is needing to update
the database.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181714#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...