Translation: 2002/09/18
original:
Http://www.libelis.com/inner-index.jsp?next=jdo.html
JDO is a new norm of persistence of Java objects. JDO is determined by SunJava Community Process.
I. Historical JDO is the comprehensive result of the persistent work of the object, and attempts to provide a full version of an object persistence. JDO is also inherited in ODMG (an Independent Committee of the Object Data Management Team, a Standardized Object Database and the object relationship mapping tool provider.
JSR # 000012 Approved in July 1999
1999-8 Group of experts: including Sun, Apple, BEA, IBM, Oracle, SAP, WebGain, etc.
2000-5 completion of the disclosure of the discussion
2000-6 introduced on Javaone
2001-3 Final draft 0.93
2001-5 Final draft 0.96 announced
2001-6 Starting on Javaone
2001-11 Final draft 0.98
Second, the target definition of the persistence of the object level.
Fully supported object models, including reference, collection, interface, inheritance, complete transparent persistence: This makes business objects completely independent of any database technology, which uses a band code enhancement mechanism (a Byte-code enhancement mechanism). Shorten the development cycle (no need to map) clearly divide businessmen and database staff 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 unform, XML files, COPERTIES files, COBOL databases on large machines, etc. What? JDO is facing A complete solution for a large information system, in such a system, information is stored in a variety of heterogeneous data sources covering J2EE, J2SE, J2ME's widespread implementation of strong transaction models simultaneously support C / S and multi-layer architecture
Third, the system
JDO Package PersistentCapable: The class with a persistent instance must implement this interface. Manage object life cycles.
PersistenceManager: Represents the connection to the data source. An application can open one or more of PersistenceManagers.
PersistenceManagerFactory: Allows an instance of a PersistenceManager from the data source, which can also be used as a connection pool.
Transaction: Allows defining transactions
Query: Allows to explicitly use the JDO query language to obtain data from the data source. NB: Objects can also be obtained from the data source by the basic positioning, implied, transparent, transparent, transparent, and transparent.
InstanceCallback: In database operation (such as Before / After Read, Before / After Write, et al), some hooks are defined to do special processing (initialization like temporary properties).
JDOEXCEPTION: Exceptions thrown in the JDO operation.
JDO also defines a help class, object identity (managed by application or data source)
JDO implementation can support or do not support compatible persistenceManager (when PersistenceManager is compatible, you can get an object reference stored in different databases).
NB: In the first release version of JDO, there is no strict definition lock and lock policy.
JDO object model
The JDO object model is basically the Object model of Java, including all basic types, reference, collection, and event interface. In addition to system-defined classes, all field types are supported (including simple, variable, and unchangeable object types [Immutable and Mutable Object Types, user-defined classes, arrays, collections, interfaces). All member variable modifiers (Private, Public, Protected, Static, Transient, Abstract, Final, Synchronized, Volatile) are inherited in java.net.socketimpl, local methods, etc. in addition to the object status All user-defined classes can be PersistentCapable. The JDO Object Lifecycle In order to access, store objects in the data source, the application must first get the connection of one or several data sources. A JDO PersistenceManager object represents such a connection. It can be obtained through the PersistenceManagerFactory class. The persistence object must be an instance of a class that implements the PersistentCapable interface. Such classes may have a persistent or temporary example.
To make an instance persistent, the programmer must call the MakePersistent method for the PersistentManager. Notifying the JDO objects for persistence or temporary, even if they can get it from JDO behavior, such as transaction management and object identity. Objects can be managed by application, or by data source agents (this most is when using an ODBMS instance, because the concept ObjectID itself is part of the ODMG model).
JDO supports a persistence model that is automatically propagated into referenced objects in this model. This mechanism is often referred to as "Persistence By Reachability" or "Transitive Persistence". This means that once a temporary object is referenced once a persistent object, this temporary object is automatically turned into persistent. For JDBC programmers, this model may be very strange, but they will find that this is most of the support from the persistent 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 =
NEW Provider
"Libelis");
Pm.MakerPersistent (APROVIDER);
// APROVIDER now Persists
Address Anaddress =
New address
"25 rue paul barruel",
"France",
"Paris");
Aprovider.address = anaddress;
// Anaddress now Persists
TX.comMit ();
PM.Close ();
Objects or by clear JDO query results from memory, or by navigation between the standard Java objects. In the end, this mechanism is very powerful, you can imagine a lasting object as a special part in the JVM stack, we call "Client Cache". Every time you try to navigate from an object to another, if this object is not in memory, JDO will automatically get from the data source and put it in the cache.
example
Suppose the APROVIDER object is already loaded, but its Address object has not yet. When you write down the following code: System.out.println (Aprovider.address.city);
The AddRess object is automatically loaded. Cache Management Auto links to Transaction Boundaries, which means that the cache will refresh in the end of the transaction, and all entities are labeled as invalid. When the next object accesses their status, automatically, transparently load it again from the data source.
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 =
NEW Provider
"Libelis");
Pm.MakerPersistent (APROVIDER);
Address Anaddress =
New address
"25 rue paul barruel",
"France",
"Paris");
Aprovider.address = anaddress;
TX.comMit ();
// Objects Are Stored Into The Data Source, Client Cache IS Discarded, References Are INVALID
tx.begin ();
System.out.println (APROVIDER);
// APROVIDER IS Refreshed from The Data Source
TX.comMit ();
PM.Close ();
Each time you modified an object, it will be labeled as "dirty" in the JDO cache.
Example tx.begin ();
Aprovider.address = ANEWADR;
// Aprovider is Marked As Dirty
TX.comMit ();
// APROVIDER WILL Updated in The Data Source
At the end of the transaction, the PersistentManager will update all JDO objects (dirty "JDO objects that are" dirty "to the data source.
Each object in the JDO cache has its own state (actually associated with a StateManager object). And the JDO specification specifies a large state and the transition between them. If you are interested, please refer to the JDO specification to learn more.
NB: These status is generally JDO providers concerned, not JDO programmers.
The development cycle In order to achieve the complete transparent persistence mentioned above, JDO defines a bytecode tool mechanism called "Enhancement" (Byte-Code Instrumentation Mechanism). Its idea is to remove all explicit database dependencies from the business class. The mapping of existing or new data sources is defined by an external metadata XML file. The JDO Enhancer reads the compiled Java file (.class file) and applies the persistence rules defined in the metadata file. Explain as follows:
Enhancements in the bytecode of the class description of the metadata file:
• Realize the declaration of the PersistentCapable interface
• The bytecode of the method declared in the interface must be implemented
• This object is labeled as "dirt" code when modifying a property.
• Code of the object from the data source when needed
• Code based on the original data (Raw Data) to the Java object specified in the metadata file
NB: Do you have to enhance the JDO specification for an intense debate in an expert group. Some experts believe that developers may be intimidated by enhancement technology. Developers who are not familiar with this technology will be surprised that bytecode enhancements, this is a fact. However, enhancement is such a general, powerful development technology, which can be used effectively in many cases. At the beginning, whenever the developer encounters a bug, it may blame the enhancer. We strongly recommend the "novice" of the enhancer to carefully look at the BCEL website (provided by the Source Forge Open Source Community). There, you can see a lot of useful information and tools about bytecode enhancement. The skilled man of this mechanism can be successfully used in their Java interface. All the familiar hands show interest.
In the traditional Client / Server system in the two-layer (Client / Server) structure, the JDO application needs to use the PersistenceManagers provided by the JDO implementation to connect it to one or more data sources themselves.
Temporary objects can hold a reference to persistent objects. Persistent objects can hold a reference to persistent objects distributed in multiple persistenceManagers. But this is not a feature that must be followed.
Most databases are removed from the business object, but the transactions still require the programmer to clearly divide (using Transaction Begin, Commit, RollBack method).
Managing the mapping between the physical model of the Java model and the data source on the disk is the responsibility of the PersistentManager. When using ODBMS, this mapping is very straightforward, but it may be very complicated when using RDBMS or simpler data sources.
Fourth, JDO and J2EEJDO have been designed to integrate into the J2EE system. JDO relies on a new Connector specification to manage an interaction between J2EE applications and JDO containers. This is described in the JDO specification as a management environment (Managed Environments, which means transactions and connections managed by the application server). The JDO container and J2EE application server interacts to get the connection of the data source (because the application has its own connection pool), and executes transactions based on the JTA-compatible transaction manager of the application server.
JDO clearly solves a major defect in the J2EE system, which is the combination of persistence and distribution in the EJB component model. These two concepts are irrelevant, but the EJB specification tries to simplify, forcing the application to use the same particle size level for persistence and distribution. This is not clear in software engineering, and it is not scalable.
Another point, EJB persistent models (CMP and BMP) are over-simplified, only limited cases, not suitable for real-purpose applications. Interested readers can be able to find a large number of EJB persistence and JDO discussions in the portal of J2EE (such as the serverside). With JDO, you can use a very elegant, universal design: Session bean to access business data objects yourself. In doing so, the application still has all the advantages of the J2EE system (distributed, transaction, connection, ...), and persistence is transparent and efficiently managed by JDO.
JDO can support a very complex mapping mechanism in a heterogeneous data source, however, the EJB / CMP model applies only to simple JDBC models.
Using JDO you don't have the complexity of your business object (however EJB / CMP does not support inheritance).
Use JDO to completely do not have a database code in your business data object (however, using EJB / BMP your business code will be doped into JDBC code)
The business handling object provides a method of processing multiple business data objects.
Business handling objects are usually non-persistent, which usually get business data objects by mixing JDO queries and navigation.
Stripping business processing methods from SessionBeans is still important because your business model can apply any infrastructure any of many applications to J2EE applications.
Resource link
•
Sun JDO Specification
•
JDO JSR Page
•
Sun JDO Site
•
Byte-code enhancement Web Sites
•
Libelis Lido Site
•
Versant Enjin
