Sash K [http://community.jboss.org/people/swishey] created the discussion "Re: JBPM 3.2.5,MSSQL 2005 - blocking in JBPM_JOB table" To view the discussion, visit: http://community.jboss.org/message/560920#560920 -------------------------------------------------------------- A bit more information.  Looks like the issue is with having a lot jobs that execute quickly, which results in a lot of inserts and deletes, which then results in a lot of updates to the indexes.  Having removed all the indexes in the jbpm_job table has greatly reduced blocking issues, but not eliminated them.  Is there anyway to configure jbpm not to delete jobs, but just mark them as complete?  I would rather have a cleanup script to remove completed jobs on a cycle and reduce index locking frequency. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/560920#560920] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Sash K [http://community.jboss.org/people/swishey] created the discussion "Re: JBPM 3.2.5,MSSQL 2005 - blocking in JBPM_JOB table" To view the discussion, visit: http://community.jboss.org/message/562945#562945 -------------------------------------------------------------- Upgraded to jbpm 3.2.9.  The situation improved somewhat, but still having serious blocking issues.   Before the upgrade over 200 jobs would create blocking issues in mssql server, after upgrade can safely do 500 jobs.  Going to 1000 jobs creates blocking issues, freezing processing for many hours.   On oracle there are no blocking issues, but that was to be expected since oracle does not block.   Upgraded to mssql 2008 as well, but also as expected, did not solve the issue.   Is there some specific information I can provide that would help in troubleshooting ?   Thank you. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/562945#562945] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Sash K [http://community.jboss.org/people/swishey] created the discussion "Re: JBPM 3.2.5,MSSQL 2005 - blocking in JBPM_JOB table" To view the discussion, visit: http://community.jboss.org/message/563167#563167 -------------------------------------------------------------- Yep, all the numbers are produced without indexes on the jbpm_job table. On Oracle the indexes are in place.  I will remove the indexes and run a test.  Will let you know as soon as have the results. Looking at how the jbpm_job table is utilized, yes, I think these  specific indexes can be removed.  Just to clarify.  From what I have seen in *our use-case*, under normal circumstances the jbpm_job table has very few entries at any point in time. Seems like entries are added and removed constantly. That being the case, I'm not sure I can see a benefit of spending the extra time/resources maintaining indexes which are never utilized. By the way, this is as good a time to explain the use-case that is failing for us.   We have a workflow with three steps synchronous steps.  The first step takes a couple to a few hundred milliseconds to complete, the second step can take anywhere from 5 to 30 seconds to complete and then the last step usually takes a half a second.    When I mentioned jobs earlier, I was referring to workflows contained the three steps just mentioned. I'm missing something, but can't seem to understand how lack of an index can play a role in a deadlock here.  I can see how full table scans on a table with a lot of data like jbpm_log can produce long delays and heavy load on db, but a deadlock seems kind a weird.  Thank you for taking the time to look at this issue! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/563167#563167] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]