Java data objects(JDO) VS Entity beans

[sk4567]

Hi All,
I am in a quandry about the performance issues between JDO and Entity Beans..which technology gives better performance..
1. Does JDO allow us to define our own database structure in terms of
tables and field types?
2. If (1), does JDO allow us to define relationships between data
elements in terms of primary and foreign key relationships?
3. How is dependent data serialised into the database?

My question is this: will using a serialisation API like JDO require that all data is loaded when objects are accessed? For example, in the browser screens ,if we are browsing through multiple information retrieved from database will we need to read in all the objects that we are browsing?

If this is the case, then I am concerned that this will dramatically increase the memory requirements at the back end when many clients are connecting. In the JDO scenario, my current understanding is that we will need one object for each object we are manipulating per client.
For entity beans, we only need one object (on the EJB server), which is accessed through multiple stub objects per client.
Moreover,can anyone cooment on any performance issues comparisons between the two?
Can you comment on this?
Regards,
Saurabh

[gabrielm]

There has been a lot of talk about this on JavaLobby.com or TheServerSide.com

JDOs have JDO-QL to create relationships.

JDOs are not RMI-powered, so you need a Session bean as a facade, if you want to access them remotely.

[gabrielm]

There has been a lot of talk about this on JavaLobby.com or TheServerSide.com

JDOs have JDO-QL to create relationships.

JDOs are not RMI-powered, so you need a Session bean as a facade, if you want to access them remotely.

[psabadin]

IMHO, JDO WILL BE the way to go but is not today. Menescu (in his J2EE patterns book) says such and I totally agree. HOWEVER, I launched my project in this direction trying to use JBoss with Castor JDO (Months ago, yet). All worked fantastic ... until the docs and forums could not help me get past some undocumented needs. Had to scrap volumes of work and went pure EJB 2.0 (JBoss). IMO the commercial JDO vendors are not far ahead (if at all) of the open-source products. JDO IS NEW AND IMMATURE - IT WILL COME BUT IS NOT HERE YET.

Bottom line: If you want to get real apps built, don't play with fire and push the technology curve too far (unless you are the infrastructure builder). Your project risk will be huge. Give new technologies time to get settled out AND DOCUMENTED.

For that matter, IMO, EJB 2.0 (CMP, CMR, etc.) is even something of a gamble but too powerful to ignore. I'm sweating through it (Thanks JBoss.org).

[ben.alex]

IMHO the best current advantage of entity beans is that you can draw on a vast body of knowledge concerning real world implementation. Sure, there are performance matters that need to be considered, but conversely there are many patterns and models to improve performance (direct JDBC for reading, custom dtos, extensive use of client-side caching etc). Add in complex (cross-server) transactional support, and we've found entity beans the way to go for now. There is no shortage of people who have successfully implemented very large projects using entity beans and sound architectural patterns.

Ben

[timfox]

Yes you can (and I have) built full-on production sites using ejb2 entity beans.
But considering IMO almost all these sites are simply using entity beans as domain objects behind a session facade, then it does seem overkill.
Even with local interfaces, every entity bean method call has to traverse the whole transaction, security, caching, pooling stack (those interceptor thingies in jboss) thus giving a performance hit.
So I would expect to see JDO as a replacement for entity beans as the technology becomes more mature and when sun finally integrates it into j2ee.
For now, entity beans can be fine if done properly - some tools provide ability to avoid the whole j2ee call stack if you know you're not going to need it. (eg mvcsoft).
As I say, we're using JBoss in production with ejb 2 cmp beans and it runs fine.
JDO is the future but not quite yet.
And anyway, if JBoss goes AOP, whether it is an entity bean of a jdo object become dynamically changeable aspects quite separate from the object itself.