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

[Joerg von Frantzius <joerg.von.frantzius@xxxxxxxxxxxxxxxxxxxx>]

Hi Mike,

I just found your blog, which is really very interesting. Apart from the articles themselves, in the comments I found some more examples of what had already, uhm, irritated me about JBoss' communications, together with a good cultural explanation ;-)

Having read your blog's article, I won't think "EJB3 == Hibernate" again, surely giving me a less biased and angry view...

Mike Keith schrieb:

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.

If that pertains to the object state incrementally getting loaded over time, resulting in more select statements being used, please see below.

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

Did you mean "Eager fetching of a relationship may be triggered..."? Spec says in 4.4.5.3:

4.4.5.3 Fetch Joins
An important use case for LEFT JOIN is in enabling the prefetching of related data items as a side effect of a query.

I really haven't seen that EAGER can be annotated as well, though, so I was wrong, that's really in the metadata as well. Do you know whether EAGER and LAZY can be dynamically turned off at runtime? I haven't seen any mention of that in "9.1.15 Basic Annotation", where the annotation is defined.

traversing foreign key relationships and allowed outer joins to be specified as well. They do not cause object fetching to occur.

I was actually ahm thinking of FETCH JOINs, while all that got typed in was the "JOIN" in it ;)

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.

Right, I totally agree. Now the difference is that with EAGER/LAZY annotations, you can define this behaviour only for a single use-case. If you have different use-cases that require different fetch behaviour, and I'll try to show below that there are those cases, then I don't see how you'd do that in EJB3 without a lot of hassle for switching eager/lazy fetching on or off at runtime for the different sets of attributes (if that's possible at all), and making the original annotations more or less useless .

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.

This might be true for long running servers with large memory, but in fat-client applications, you have to optimize startup time and response time without simply loading everything into memory. When you have a GUI table showing only some attributes of a class, and you have a huge number of objects to be shown, then you'll want to optimize everything possible to have it loaded as fast as possible, including not fetching columns you don't need to show, and eager fetching of single-ended associations. If the number of objects is only big enough, you can also run into memory constraints, and lazy-loading will help here as well.

Showing this GUI table is use case 1, and any other GUI table showing a different set of columns for the same class is use case n, and you'll want to optimize for each. Then you might have e.g. a details view below that GUI table, showing the details of the selected GUI table row, containing some more attributes than the GUI table, but not all, because you don't want to show that gigantic TIFF picture there but somewhere else. That's another use case, and so on.

In the rare case that the user now clicks through the whole table, looking at all attributes in all possible views, then he might indeed have in the end accumulated all values of all attributes in memory. But he got to see everything as quickly as possible on every click of a button or selection of a GUI table row, and that's what counts here. I don't care much if in a GUI application the overall number of select statements over time is "suboptimal", if response time is optimal. In fact response time would be absolutely compromised by trying to optimize the overall number of select statements.

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

Well, explaining it can't be so hard, can it ;-)

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.

I hope that I could make my case that they have benefits for fat-clients, or I hope I'll learn how to do without them.

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

Thank you for discussing these issues here,
Jörg.