Introduction to JDO Architecture
Note: The author retains all rights to the article, but welcome to reprint, please indicate the source and author information: mail: Wafd@hotmail.com
Why use JDO
Java developers have several ways to access databases: serialization, JDBC, object-oriented mapping tool, object-oriented database, and entity EJB. Then why do you want to introduce other storage architectures? The answer is that there is a certain limit on each of the plans that implements the store above. JDO is trying to solve these restrictions.
Serialization: It is a transmission mechanism established by Java. It can convert the information of the object into a series of bytecles, which can be transferred to the network or stored in a file. Serialized use is very simple, but he is still limited. It must immediately access the features of the object, and it is not suitable for accessing large amounts of data. When changing an object's properties, if there is an error, it cannot achieve "rollback", so it is not suitable for the application requirements for the data integrity, and does not implement multiple threads or programs asynchronous read and write data. All these shortcomings make serialization unable to meet most of the data storage requirements.
JDBC: Many programmers use the JDBC API to operate the relational database. JDBC overcomes the disadvantages of many serialization: it can operate large quantities of data, with mechanisms that ensure data consistency, support the concurrent access, which can be used very mature SQL language. Unfortunately, JDBC is not as simple as serialization. The relationship example of JDBC use cannot be used to store objects, so you have to give up to use object-oriented principles to store data in your code.
Object-oriented mapping tool: Architecture created by a software vendor can be mapping between objects and relational databases. This object-relational mapping support allows you to focus on the design of the object model without having to care about the match between object-oriented and relational databases. Unfortunately, every object-relational mapping products have a standard for his own manufacturers. You have to move your code as a separate manufacturer. If this vendor increases product prices or stops support for BUG changes, you must rewrite your code when you use other manufacturers to use other vendors.
Object-oriented database: Better choice for object relationship database maps to develop a new object stored in the database using some software vendors. This object-oriented database is often simpler than the object relationship mapping software. One of the purposes of the ODMG organization is to create a standard API access to an object database. Most vendors have followed the requirements of ODMG organizations, so it is also solved due to the troubles that manufacturers achieve different. However, some companies are hesitant from the relational database to object database because there are a lot of data stored in the traditional relational database. Although some database analysis tools can be used to target transplants between object databases and relational databases, a large amount of data storage is still a relational database.
Entity EJB: The entity EJB is introduced into the enterprise application of the Java platform. Entity EJB is a component that describes persistent data information in the database. EJB uses a method similar to an object-relational map that provides a persistent data for object-oriented representation. Unlike the object relationship software, EJB is not limited to the relational database; the persistence information it describes can be from an enterprise information system (EIS) or other storage devices. Moreover, EJB requires a strict standard to implement its manufacturers to follow this standard. Unfortunately, the EJB standard is slightly lacking in object-oriented, such as some advanced features: inheritance, polymorphism, and composite relationships. In addition, the EJB code is complicated, and it is a heavyweight setup requires a lot of resources to consume many resources. However, the session bean in EJB has many advantages, so the JDO specification defines how JDO is integrated with them.
JDO: JDO integrates many of the above persistent mechanisms, which makes it simple as the Persistence class in JDO is as simple as creating a serialization class. JDO supports storage, data consistency, concurrent processing, and JDBC query functions. Like object-relational mapping software and object databases, it allows the use of object-oriented advanced features such as "inheritance". It avoids the strict specification from vendor definitions like EJBs. Like EJB, JDO does not specify any particular backend database. However, here is still to say, there is no "Wanling Dan" in the world. Therefore, using JDO is not for each application. Many applications can use other more ideal storage mechanisms.
JDO architecture
Below I started to make a simple introduction to the JDO architecture.
The figure below shows the main parts of the JDO architecture:
JDOHELPER: Javax.jdo.jdoHelper class has some static assistant (helper) method. This method can get a lifecycle of a lasting object can also be used to create an instance of a PersistenceManagerFactory that is not related to specific implementation vendors, where the factory (FACTORY) mode is used.
The PersistenceManagerFactory: Javax.jdo.PersistenceManagerFactory class can be obtained through the assistant method of the JDOHELPER class, which is a standard factory class, and he can create a PersistenceManager class.
The PersistenceManager: Javax.jdo.PersistenceManager interface is a major JDO interface that the application is often used. Each PersistenceManager is responsible for controling a set of persistent objects and he can also create a new persistent object or delete an existing persistence object. There is a relationship between Transaction and PersistenceManager, while PersistenceManager is an extent and query factory class, that is, both objects can be created via PersistenceManager.
PersistenceCapable: User-defined persistence classes must extends implementation of the PersistenceCapable interface. Most JDO-implemented vendors provide a "Enhancer" feature that increases the implementation of the PersistenceCapable interface to the persistence class you want to implement. That is, it is actually not going to implement this interface at all.
TRANSACTION: Each PersistemceManager and Javax.jdo.transaction are one or one. Transactions is used to handle transactions, which allows persistence data to be added to the data table in batches, and the data rolls back if an exception occurs.
Extent: java.jdo.extent is a logical view of the class that maps the specific table in the database. Extent can have its own subclasses, it is obtained through PersistenceManager.
Query: java.jdo.Query interface is implemented with specific vendor JDO, which is responsible for handling JDO Query Language (JDOQL), which is finally interpreted as actual database SQL language. The same is also obtained by PersistenceManager.
The following example shows how the JDO interface operates and executes a query and updates the persistence object.
Example: JDO interface interaction
// Get the PersistenceManagerFactory through the assistant class
PersistenceManagerFactory Factory =
JDOHELPER.GETPERSISTENCEMANAGERFAACTORY (SYSTEM.GETPROPERTIES ());
// Get the PersistenceManager object by PersistenceManagerFactory
PersistenceManager PM = factory.getPersistenceManager (); // Create and start a transaction
Transaction tx = pm.currenttransaction ();
tx.begin ();
/ / Query researchers for a weekly working time of the Employee table greater than 40 hours
Extent ex = pm.getextent (Employee.Class, False);
// Get a query
Query Query = PM.NewQuery ();
// Set the range of this Query effect, that is, query that table or recordset
Query.Setcandidates (EX);
Query.setfilter ("Division.Name == /" research / " " && avghours> 40 ");
Collection results = (collection) query.execute ();
Employee EMP;
Iterator ITR = Result.iterator (); itr.hasnext ();) {
EMP = (Employee) ITR.NEXT ();
Emp.SetSalary (Emp.getsalary () * 2);
}
/ / Submit a record release resource
TX.comMit ();
PM.Close ();
Factory.close ();
The above code snippet includes several major interfaces of JDO, where you can use a rough impression on the use of JDO each interface, and the JDO interface in the actual application is also used.
JDO exception
JDO will not throw out the usual runtime exception, such as NullPointersExceptions, IllegaLaRgumentException, etc. It only throws JDOException exception. The structure of JDOExcet is shown in the figure below. This is a inherited hierarchy. From their literal meaning, they can see their use. It is not detailed here. To understand the JDO unusual hierarchy, you can refer to their Javadoc. .
