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.
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964917#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...