[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
[Taking this more technical debate off eclipse.foundation]

Max Rydahl Andersen schrieb:
Could you tell what these implementations are?
There exists at least two implementations of this and more to come.

The two I know is JBoss/Hibernate EntityManager  (entitymanager.hibernate.org) and Oracle  (http://www.oracle.com/technology/ejb3/index.html).
Others here can probably list more (I saw Robert mention 2 more)
Alright. I'm surprised ;-)
Especially seeing Oracle already supporting "out-of-container" usage
that makes use of it? For JDO 2.0, I know at least of one in production  use. We
created that one using JPOX, though, not VOA.
Do you know of any RCP application, or some other client application  with a GUI,

No, I don't know of any RCP application using EJB3 nor JDO2 (before the  one you just mentioned).
But I know of a couple that uses Hibernate with Eclipse RCP and they  should have
no apparent problems using it (but that of course is not what you asked  for ;)
RCP on Hibernate is still news to me! I had to make use of JDO fetch-groups to get things perfomant enough when e.g. displaying large tables, and I believed Hibernate eager-fetching support too unflexible for this. Fetch-groups also allowed me to lazy-load large BLOB columns, something that Hibernate in it's documentation calls "a checkbox feature that Hibernate needs for marketing purposes", although it is feature that was absolutely essential to me. It is things like that which cause my doubts on Hibernate, and EJB3 in consequence.

For anyone else interested, here is a little list of explicit Hibernate restrictions (sorry, couldn't resist to post this ;)
Of course it is good that these restrictions are made explicit in the documentation, though!
Nice. I did not know JDO2 defined ways to persist arbitrary collections  (EMF collections) efficiently,
are you sure that is not "just" JPOX features they are utilizing ?
Elver at least does make use of JPOX extensions, though I don't know which exactly as I have learnt about Elver only today... For our own brew, we are using EMF to describe the model, but the implementation classes do not extend EObjectImpl (though they still implement the interfaces, of course). Elver makes use of EObjectImpl.
EMF has some very intrusive design issues that makes it very hard to  persist and query completely and efficiently -
would be interested in hearing how much they have solved of that.
What exactly are these design issues? E.g. Bidirectional integrity?