What is JDO?

Translation: 2002/09/18
Original: http://www.libelis.com/inner-index.jsp?next=jdo.html

JDO is a new specification for Java object persistence. JDO via Sunjava Community process identification.
First, HistoryJDO is a comprehensive result of object persistence, trying to provide a complete version of an object's persistence. JDO also inherits from the ODMG (Object Data Management Group, an independent committee that standardizes the object database) and the Object Relational mapping tool provider.
JSR #000012 approved in July 1999
1999-8 formed panel of Experts: Sun, Apple, BEA, IBM, Oracle, SAP, Webgain, etc.
2000-5 completion of the draft public comments
2000-6 introduced on the JavaOne
2001-3 Final Draft 0.93
2001-5 Final Draft 0.96 released
2001-6 starts on the JavaOne
2001-11 Final Draft 0.98

II. ObjectivesDefines the persistence of an object level.
Fully supports the object model, including references, collections, interfaces, inheritance
Fully transparent persistence: This makes business objects completely independent of any database technology, using a bytecode enhancement mechanism (a byte-code enhancement mechanism).
Shorten the development cycle (no more mapping required)
Clearly divide the business and database personnel in the development team.
Universal Persistence
? JDBC is limited to rdbms,jdo potentially handle any type of data source, including RDBMS,ODBMS,TP monitoring processing, ASCII unformatted files, XML files, properties files, COBOL databases on large machines, etc.
? JDO is a complete solution for large information systems in which information is stored in a variety of heterogeneous data sources
Covering the wide implementation of Java EE, J2SE and J2ME
Robust Transaction model
Support both C/s and multi-tier architectures

third, the system JDO PackagePersistentcapable: A class that has a persistent instance must implement this interface. Manage Object lifecycles.
PersistenceManager: Represents a connection to a data source. An application can open one or more persistencemanagers.
Persistencemanagerfactory: Allows an instance of a persistencemanager to be obtained from the data source, and this factory can also be used as a connection pool.
Transaction: Allow defining transactions
Query: Allows you to explicitly and declaratively use the JDO query language to fetch data from the data source. NB: You can also obtain objects implicitly and transparently from the data source by using the basic positioning between references.
Instancecallback: In database operations (such as Before/after read, before/after write, etc.), define hooks for special processing (like initialization of temporary properties).
The exception that is thrown in the jdoexception:jdo operation.

JDO also defines help classes, object identities (managed by an application or data source)
The JDO implementation can support or not support compatible PersistenceManager (you can get an object reference stored in a different database when the PersistenceManager is compatible).
NB: In the first release of JDO, there is no strict definition of lock and lock policies.

JDO Object ModelThe JDO object model is essentially a Java object model that includes all the basic types, references, collections, and event interfaces.
In addition to the System definition Class (system-defined classes), all field types are supported (including simple, mutable and immutable object types (immutable and Mutable objects types), user-defined classes, arrays, collections, interfaces).
Supports all member variable modifiers (private, public, protected, static, transient, abstract, final, synchronized, volatile)
All user-defined classes can be persistentcapable except that the object state is dependent on inaccessible or remote objects, that is, inherited from Java.net.SocketImpl, local methods, and so on.

Jdo object life cycleIn order to be able to access and store objects in the data source, the application must first get a connection to one or several data sources. An JDO PersistenceManager object represents such a connection. It can be obtained by Persistencemanagerfactory class. The persisted object must be an instance of the class that implements the Persistentcapable interface. Such a class might have both a persistent or a temporary (transient) instance.

In order for an instance to persist, the programmer must invoke the Persistentmanager Makepersistent method. It is important to notify the JDO objects to be persistent or temporary, even if they can be obtained from the JDO behavior as temporary, such as transaction management and object identification. Object identities can be managed by the application or by the data source proxy (mostly when using the Odbms instance, because the concept Objectid itself is part of the ODMG model).

JDO supports a persistence model in which persistence is automatically propagated to referenced objects. This mechanism is often referred to as "extended persistence (persistence by reachability)" or "delivery persistence (transitive persistence)". This means that once a persisted object references a temporary object, the temporary object automatically becomes persistent. This model may be strange for JDBC programmers, but they will find that this is the support that programmers in most cases want from the persistence framework.

Example: PMF = (persistencemanagerfactory) (Class.forName ("Com.libelis.lido.PersistenceManagerFactory"). newinstance ());
Pmf.setconnectiondrivername ("Versant");
Pmf.setconnectionurl (dbname);
PM = Pmf.getpersistencemanager ();
tx = Pm.currenttransaction ();
Tx.begin ();
Provider Aprovider = NewProvider ("Libelis");
Pm.makerpersistent (Aprovider); Aprovider now persists
Address anaddress = NewAddress ("Rue Paul Barruel", "France", "Paris");
aprovider.address = anaddress; Anaddress now persists
Tx.commit ();
Pm.close ();

Objects are either obtained from memory through explicit JDO query results, or through navigation between standard Java objects (navigation).

Finally, this mechanism is so powerful that you can imagine a persistent object as a special part of the JVM heap, which we call "client cache". Every time you attempt to navigate from one object to another, JDO automatically fetches the object from the data source and places it in the cache if it is not already in memory.

Example
Suppose the Aprovider object is already loaded into memory, but its address object is not yet. When you write the following code: SYSTEM.OUT.PRINTLN (aProvider.address.city);

The Address object is automatically loaded. Cache management is automatically linked to the transaction boundary (transaction boundaries), which means that the cache will be refreshed at the end of the transaction and all entities are marked as invalid. The next time the object accesses their state, it is automatically and transparently loaded from the data source again.

Example PMF = (persistencemanagerfactory) (Class.forName ("Com.libelis.lido.PersistenceManagerFactory"). newinstance ());
Pmf.setconnectiondrivername ("Versant");
Pmf.setconnectionurl (dbname);
PM = Pmf.getpersistencemanager ();
tx = Pm.currenttransaction ();
Tx.begin ();
Provider Aprovider = NewProvider ("Libelis");
Pm.makerpersistent (Aprovider);
Address anaddress = NewAddress ("Rue Paul Barruel", "France", "Paris");
aprovider.address = anaddress;
Tx.commit (); Objects are stored into the data source, client cache is discarded, references are
Tx.begin ();
System.out.println (Aprovider); Aprovider is refreshed from the data source
Tx.commit ();
Pm.close ();

Each time you modify an object, its corresponding entity in the JDO cache is labeled "dirty" (dirty).

Example Tx.begin ();
aprovider.address = Anewadr; Aprovider is marked as dirty
Tx.commit (); Aprovider would updated in the data source

At the end of the transaction, Persistentmanager updates all of the JDO objects (dirty objects) labeled "Dirty" to the data source.

Each object in the JDO cache has its own state (in fact, they are all associated with a Statemanager object). and the JDO specification sets a large stack of states and transitions between them. If you are interested, please refer to the JDO specification for detailed information.
NB: These states are generally the concern of the JDO provider, not the JDO programmer.
Development CycleTo achieve the fully transparent persistence mentioned above, JDO defines a bytecode tool (Byte-code instrumentation mechanism) called "Enhanced (Enhancement)". Its idea is to eliminate all explicit database-dependent code from the business class. Mappings to existing or new data sources are defined by an external metadata (metadata) XML file.
The JDO intensifier reads the compiled Java file (. class file) and applies the persistence rules defined in the metadata file. Examples are as follows:

Enhancements are added to the byte code of the class that the metadata file describes:
• Implementation of Persistentcapable interface declaration
• The byte code of the method declared in this interface must be implemented
• Code marked "Dirty" when an attribute is modified
• Get the object's code from the data source when needed
• Code from raw data in the metadata file to the Java object map from the source data
NB: In the Panel of Experts, it has been hotly debated whether enhancements should be included in the JDO specification. Some experts say developers may be intimidated by enhanced technology. It is a fact that developers unfamiliar with this technology will be surprised by bytecode enhancements. But enhancements are such a versatile, powerful development technology that can be used effectively in many cases. At first, the developer may blame the enhancer whenever a bug is encountered. We strongly recommend the "novice" of the intensifier to take a closer look at the Bcel website (provided by Source Forge Open Source community). There, you can see a lot of useful information and tools about bytecode enhancements. This mechanism can be used successfully in their Java interface. All the proficient have shown interest.

consolidating in a two-tier (CLIENT/SERVER) structureIn the traditional client/server system, JDO applications need to connect themselves to one or more data sources using the persistencemanagers provided by the JDO implementation.


A temporary object can hold a reference to a persisted object. Persistent objects can hold references to persistent objects that are distributed across multiple persistencemanagers. But this is not an attribute that must be obeyed.
Most database-related code is removed from the business object, but the transaction still requires a clear division of the programmer (using the transaction begin, commit, and rollback methods).
It is Persistentmanager's responsibility to manage the mapping between the physical model of the Java model running in memory and the data source on disk. This mapping is very straightforward when using Odbms, but can be very complex when using an RDBMS or a simpler data source.
iv. jdo and Java EEJDO has been designed to integrate into the Java EE system. JDO relies on a new connector specification to manage the interaction between a Java-EE application and the JDO container. This is described in the JDO specification as an administrative environment (managed environments, meaning that transactions and connections are managed by the application server itself). The JDO container interacts with the Java EE Application Server to obtain a connection to the data source (since the application has its own connection pool) and performs transactions based on the JTA compatible transaction manager of the application server.

JDO explicitly solves a major flaw in the Java EE system, that is, the EJB component model combines persistence and distribution. The two concepts are irrelevant, but the EJB specification attempts to simplify, forcing the application to use the same granularity level for persistence and distribution. This is not clear from a software engineering perspective and is not scalable.
Another point is that the EJB persistence model (CMP and BMP) is too simplistic to cope with a limited situation and is not suitable for realistic application needs. Interested readers can easily Java EE portals (e.g. the serverside) find plenty of EJB persistence and jdo discussions.
With JDO, you can use a very elegant, universal design: Session beans (Access business processing objects) to access business data objects themselves. In doing so, applications still have all the benefits of the Java EE System (distributed, transactional, connected, ...). , and persistence is managed transparently and efficiently by JDO.

JDO can support very complex mapping mechanisms in heterogeneous data sources, however, the EJB/CMP model applies only to simple JDBC models.
With JDO you have no limitations on the complexity of the business object (however ejb/cmp does not support inheritance).
Use JDO to completely have no database code in your Business data object (however, using Ejb/bmp your business code will be doped into the JDBC code)
A business processing object provides a way to handle multiple business data objects.
Business processing objects are typically non-persistent, and they typically get business data objects through mixed JDO queries and navigation.
Stripping business processes from Sessionbean is still important because your business model can apply any infrastructure in many applications to Java EE applications.
Resource Links
Sun JDO Specification
JDO JSR Page
Sun JDO Site
Byte-code Enhancement Web sites
Libelis LiDO Site
versant Enjin