[news.eclipse.technology.ejb-orm] Re: JDO fetch-groups important for RCP

[michael.keith@xxxxxxxxxx (Mike Keith)]

Joerg von Frantzius wrote:

> Maybe that's a misunderstanding, as JDO fetch-groups can be used both 
> for eager-fetching /and /lazy-loading. While in EJB3 you would use a 
> JOIN query on the association fields to be eager-fetched, in JDO2 you 
> would just put them in a fetch-group. That puts control over fetching 
> into a single conceptual place, so that you can easily distinguish 
> fetch-behaviour for different use-cases in the metadata. It doesn't 
> disperse that information on metadata, code and queries as in EJB3 
> currently.

Yes, thanks Joerg, I am aware of how fetch groups work (I was part of the 
JDO expert group when they were being discussed :-). I was actually just 
comparing the performance of fetch groups with lazy loading of attributes, 
not saying that they were equivalent. My point was that the usage of fetch 
groups more often leads to worse performance than better. This is not an 
invariable, of course, but was our experience. 

Note that in EJB 3 the eager/lazy loading is defined in the mappings, not 
in the EJB QL. Lazy fetching of a relationship may be triggered, though, 
by using a FETCH JOIN in an EJB QL statement. Simple JOIN statements just 
call out the semantics of what is happening when traversing foreign key 
relationships and allowed outer joins to be specified as well. They do not 
cause object fetching to occur.

> > when there is a large number of columns in a table mapped to one 
> > object or when there is a single attribute that is very large (e.g. a 
> > LOB). All other cases will normally end up causing worse performance, 
> > not better.

> Maybe that conclusion is due to the same possible misunderstanding that 
> fetch groups would only declare lazy loading.

Not sure but that we may be talking cross purposes here. Fetch groups 
cause a group of attributes/relationships to be loaded together and define 
semantics for operations on the object. This is very much related to 
eager/lazy loading of the object state/related objects and eager/lazy 
loading is typically the reason why some people ask for fetch groups.

> > because they are prone to misuse and a complication that we did not 
> > feel was warranted in the specification.

> What misuse could that be? What complication do they add other than for 
> the ORM implementation?

Defining a fetch group is typically done as a means of trying to separate 
the loading of some attributes from the loading of others. What ends up 
happening is that applications define fetch groups for specific access 
patterns or portions of code that access the object. The default fetch 
group would pull in a part of the data, and then as the object gets used 
by other portions of the application other parts of the object get pulled 
in. Over time the stable state is that all of the data ends up getting 
accessed, but given that most products have some kind of cache, the 
original object just kept getting incremented with its additional data. 
This would have involved multiple trips to the database when the cost of a 
single trip would have sufficed, and for attributes would not have been 
much more costly than pulling back only parts of the object.

The extra complication arises when the specification has to explain what 
fetch groups are and when they are useful, in the metadata required for 
them to be specified, the extra API needed for the user to be able to 
specify them, and the vendors having to implement and support them. It 
turns out that tyhe cost of the runtime to have to even maintain fetch 
groups was noticable, so any benefits really were not clear.

Anyway, if fetch groups work for you then great. Choose a product that 
supports them the way that you like them done. TopLink will still provide 
support for them (although we do warn people about using them :-). This is 
only the first version of the common POJO persistence spec and they are 
not the only thing that is outside the spec. Right now the spec includes 
the most commonly used features of persistence. If people use them and get 
benefit from them across enough vendors then I would not rule out 
introducing them in a subsequent version of the spec. Thanks for your 
input.

Regards,
-Mike