JDO objects can run in a managed environment (typically a container with in an app server) or they can run in a non-managed environment (J2SE, client-server, batch process, Web Server, PDA...). That's why JDO is nice, it is database agnostic and architecture independent.
Hope this helps.
Joined: Sep 01, 2004
besides this JDO 2 provides:
* a complete standard for O/R mapping * full support of Java models including interfaces, collections, maps, arrays and inheritance * navigation between object in pure Java (no specific API) * manipulation of objects in pure Java * transaction API * a rich query language * a way to work on disconnected graphs through Attach/Detach * portability of persistence layers (at least 30 JDO implementations available today)
Joined: May 12, 2003
I read in one article that Entity bean diesn't support primary key generation but JDO does.
How does JDO support automatic primary key generation?.Why CMP doesnot?.
Thanks Priya Shankar
Joined: Sep 01, 2004
JDO supports automatic primary key generation. The standard defines Datastore IDs that are IDs generated and managed by the JDO implementation. These ID are invisble in the Java class, so there is nothing to do in the Java application.
JDO also supports Application ID, where ID are managed either by the application, the programmer or the database (sequences, triggers, auto-incr columns...). In that case the attributes part of the PK are visible in the Java class.
Please note that best JDO implementations like LiDO supports composite PKs and PKs containing FKs.
The EJB 2 specification says nothing about primary key generation, but most of application servers support it.
In the end what really matters is the set of features supported by the standard, and JDO has a rich set of feature since version 1, including being datastore agnostic and with many implementations like Lido that supports XML, File and relational datastore, object relational concepts like identifying relationships, autoincrement columns, sequences and others. In JDO 2, non standard features for object relational mapping are going to be standarized as many other user requested features are to included like aggregated queries, refinement of callbacks, detach/attach, etc.
I'm confident that today JDO is the best choice within the existing datastore access mechanisms.
In october Sun decided to clean the situation regarding the standards for persistence. It has been decided that some experts (3 vendors + 3 independent) from the JDO expert group will join the EJB 3 expert group (it has been done in the meanwhile). The goal is to create a future common standard for O/R mapping (the name still has to be defined) that could be used by future JDO and EJB releases. Also what is important is to maintain a good pluggability level in the EJB server so that anybody can choose the best persistence implementation.
JDO will certainly go on. As SDO and EJB will.
It is very important to compare products rather than standards. Each product implement a vision and has a core technology that is independent from standards, then they implement a compiance layer with one or multiple standards.
JDO is the most modern & popular standard for Java data access & persistent storage. Basically, it handles the chores of database access and mapping so you can concentrate on requirements and using your object model.
This is the most natural and productive way to develop with Java or OO languages. Previous approaches such as JDBC and BMP have had excessive overheads due to the focus on coding data access rather than actual application. JDO also improves over historical CMP approaches in many ways.
Great question about the container! JDO provides management of persistent data on a per-session basis (PersistenceManager). Independent changes eg for separate web clients can be handled separately. JDO handles this simply and correctly, making it clearly visible what should be going on, whereas CMP relies a little too much on 'magic technology' making it much harder to debug what should be going on inside the appserver.
JDO can be run inside or outside the container and can also be used with lightweight web servers eg Tomcat. These lightweight options are often preferred as being much easier for developers to test, debug and deploy business functionality.
Test/ debug cycles can for example be 3 - 5x more productive, with business logic able to be debugged outside the container using simple JUnit tests. Even logic destined for use in a J2EE container, can be debugged separately if implemented with JDO, making the QC cycle a lot easier for developers.
The future JSR-220 standard is a proposed step to merge the benefits of JDO technology onto EJB. Customers have been requesting better EJB facilities for years now and this would be great but ratification of this step would still be a year or more down the road after JDO2.