As usual, there was no response but I was not expecting any. I have gone around jbpm so that variables are cached once loaded since load time for each task is a killer. From what I have seen, jbpm 3 is not just designed for high scalability when you have to hit the database for each variable and task. That's my take though... There is one thing I tried, I changed the hibernate hbm files on the jar to see what the effects of changing batch size will be. A related article can be found here; http://www.mkyong.com/hibernate/hibernate-fetching-strategies-examples/  .

Problem lies in the db schema. It is an ORM db schema. I don't think people have thought of task instance. Problem is task instance on its own is useless. It only gives you the task name, and few jbpm specific stuff. This is code I am maintaining so task details are in the variables such as what's being worked on but if I want to display what's being worked on, it means I have to get the task list and then get variable for each task. Now if you do a sql to get all the tasks then hit the variables for each task " n sql selects for n tasks min".. That's not really usefull... U would think the db schema would contain a column that defines a custom field or two where you can use it for whatever purpose. Granted this kind sucks from a purist point of view but in real world, it helps cut down on speed... so I am not sure if it is hibernate that's really screwed up...

Also, I have not see any written documentation and asked and got no reply about updating jbpm 3 to jbpm 5.