batch-size of jbpm runtime objects
recently someone queried us about the batch size of the jbpm runtime objects and why they were not set to a proper default. based on Max's input on what batch-size on the class level actually is, i think that jBPM can't really define a good batch-size except the default for 1.
"Max" wrote:
> | Is there a reason why batch-size isn't set to a reasonable default
> | on the various jBPM runtime objects?
>
> would that make sense ?
depends.
Let me see if i can explain this via pure email (i normally do fancy drawings and gestures to explain the voodoo-magic)
Basically/naivelly speaking batch-size defaults to 1.
Meaning that when Hibernate is asked to get some object by id from the db, e.g 42 it will try and load this single object by id 42.
By increasing this on the class level to eg. <class name="Blah"
batch-size="5" ..>
then instead of just loading the one(1) matching the given id(42) hibernate will look in its cache and see if there is up-to 5 more non-initialized proxies that can be fetched. If there is hibernate will do something like "select ... from Blah where id in (42, 32, 4, 3, 17)"
instead of just id = 42. Hence optimally a reduction in requests to the db of factor 5.
So, batch-size > 1 on classes make sense if you often have a bunch of un-initialized objects in the session that it would be relevant to get in batches of selects instead of single selects.
The above is for class instances; but the same is valid for collections.
They too
have a batch-size option. This is not about getting a 20 element collection in e.g. 4 selects it is about loading multiple complete collections in fewer selects.
The same logic as above applies. e.g. blah.getChildren() is internally viewed as "get the children collection for blah with id 42" (assuming blah's id is
42 of course).
Here the default is to get that one collection, but alternatively Hibernate can look around and see if there are more uninitialized *collections* of the same role (Blah.children) and load those in one go. Again, this can be a very efficient optimization to e.g. load hiearchies of entities.
There are alternatives such as fetch="subselect" which instead of using in
(x,y,z) creates
a sub query select based on what you just fetched. This requires a bit more drawings for me to explain (and i actually did that when you here - remember ? :)
> should i have a look at what that is ?
yes.