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/ .
Well, first of all you are asking jBPM 3 question. As to my knowledge jBPM 3 has been transformed into Activiti and moved out. jBPM 5 is a completely new product and is rooting from the Drools. I can be wrong on this, so forgive me if I am.
Secondly, your question mostly relates to how Hibernate works/performs. Our company currently working with jBPM 5.2 and we had problems with some SQLs containing in orm.xml files coming with jBPM. The SQL’s are less then optimal and Firebird DB is dying executing them. But it is not jBPM but Hibernate (and perhaps Firebird). Our approach was to not using “bad” SQLs but write our own optimized SQLs and execute them via Hibernate’s Native Query mechanisms.
As to jBPM 5 performance - we do not have any complains so far.
Hope this helps.
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.
Jbpm 3 might not be optimized for your needs out of the box. But you can easily create your own flavour task instances (look at the TaskInstanceFactory) - and link this to any domain object you choose. The hibernate mapping is then completely up to you.