[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ejb-orm] Re: correction: EJB3 is specified for use outside of a J2EE container
Max Rydahl Andersen schrieb:
well, one learn every day ;)
I'm doing my best ;)
Have no idea why querying isn't sufficient for you since you here can very
precisly specify what part of your object graph you want to load.
I just learned that you probably are thinking of FETCH JOINs here. I still can't imagine how I could solve my problems using EJB3, though, as lazy loading of primitive fields can only be declared statically (it can't be swiched on and off dynamically). To me this seems way less flexible than JDO fetch groups in general, which give me total dynamic control of what is fetched when, with that control accessible in a central place (not being dispersed on static declarations and dynamically constructed queries).

Let's explain the problem: in my RCP application, the first thing the user sees is a JFace TableViewer containing ~1500 ordered rows. Startup-time must be as fast as possible, so the application window must be visible as fast as possible, and the user must be able to start clicking around as soon as possible. Most of all (s)he must not have to wait for all values of all rows being retrieved from the DB before being able to use the application.
Using JDO fetch groups:
First I retrieve all row objects as on ordered List using an empty fetch-group, which means that only the ids are retrieved in a single, quickly executing SELECT statement, as only a minimum of data is retrieved. I can then hand in that ordered List as input to the (virtual) TableViewer, which will invoke getters only for the visible row objects. A fetch-group is in place that will retrieve all values in a single SELECT per object upon first field-access. So for the first n visible rows, we have n SELECTs here. When they are done, the user can start working.

In the background, a thread goes and retrieves all values of all row objects in a single SELECT, resulting in the level-2 cache being filled. When the user scrolls down the tableviewer, the displayed values are taken from the level-2 cache, without perceivable delay.
So, before the user can start clicking, we have n+1 short-running SELECTs, with n being the number of initially visible rows, plus 1 long-running SELECT in the background.

How would you solve that with EJB3?
So, just to be "fair" i'll do the same for jpox:
http://www.google.com/search?hl=en&lr=&q=%22jpox+does+not+support%22+site%3Awww.jpox.org&btnG=Search
interesting, eh ? 10 hits in hibernate vs 44 jpox :) (please notice my  smiley here! Those two searches are totally irrelevant)
I noticed that smiley, which is most appropriate as the results mostly are year-old forum entries probably mostly being out of date... Yeah, but it was me who started being unfair :)
Again - it seems being honest about what is doable and what is not doable  (in
a good way) via ORM/EJB3/Hibernate is a bad thing ?!
It absolutely is a good thing! I wished there was an up-to-date list of features not supported by JDO in general and JPOX in particular (apart from JPOX confirmed bugs or feature requests).
 EObjectImpl.
This is one of the intrusive design issues I don't like.
Well, EObjectImpl gives you a superb meta-model in comparison to Java reflection, out-of-the-box and DTD-conformant XML-serialization, super-flexible change notification, validation, and probably lots of other nice stuff I forgot right now. Just that you surely know what you don't like here ;)

Some things don't work with these features, e.g. support for array types is not possible. Also EMF currently doesn't support generics, which is a pity.