is EJB 3.0 a clone of hibernate?

　　 SummarySun's EJB 3.0 specification is in its final "sprint" phase, and many companies are busy working to follow this specification. One of the many advantages that the latest version of this EJB specification provides is more prominent in its database capabilities, but some developers feel that this specification is only a "clone" version of the Hibernate persistence storage engine. Are you sure? This article is to discuss this issue.

Practice has proven that hibernate is one of the finest persistent storage engines created for the Java language. So far, I remember clearly the first time I used hibernate work. At the time, we had a ready-made persistent storage engine, but the engine would consume a lot of system resources and never really worked properly. Surprisingly, Hibernate "instantly" solves our persistent storage problem! It's a godsend. Unconsciously, the time is fast advancing to today. EJB 3.0 has surfaced again, and soon we will be planning to upgrade our current EJB 2.x server to this later version. However, a careful analysis of the persistent storage changes made in EJB 3.0 may be surprising-is this not a "clone" of Hibernate? did Sun really "steal" the design from hibernate? My answer is that the situation is much more complicated than that.

　　 First, EJB 3.0

One of the important goals that EJB 3.0 must achieve is to make it a more useful and easy-to-use development tool. Sun's Linda Demichiel recognizes that in order to achieve this goal successfully, EJB 3.0 must be based on an existing library that developers are using today; otherwise, it can lead to a difficult upgrade operation and may not be enough attention. As a result, members from Oracle,jboss,apache,bea,novell,google and other experts were invited to participate in the elaboration of this norm. The goal of the team is to produce a specification that makes EJBS easier to develop and creates a persistent storage standard that makes it easy for developers to implement upgrades.

When the team started developing EJB 3.0 specifications, they quickly realized that many of these features should be functionally aligned with all major vendors and libraries. We will discuss these features in the following sections.

(i) Entitymanager

This entitymanager is responsible for handling a transaction. In Jdo, it is called a persistent storage manager, and in hibernate it is called a session. In the GlassFish project, Entitymanager is described as follows:

In fact, a Entitymanager instance is associated with a persistent storage context. A persistent storage context is a set of entity instances in which any persistent entity is the only one entity instance. In this persistent storage context, the entity instance and its lifecycle are manageable. This interface defines a method for interacting with a persistent storage context. The Entitymanager API is used to create and delete persistent entity instances-to find entities and query entities through their primary key.

This collection of entities that can be managed by a given Entitymanager instance is defined by a persistent storage unit. A persistent storage unit defines a collection of all classes, which are linked or grouped by applications, and they must coexist in their mappings to a single database.

(ii) named queries

A named query is a predefined query that is given a name so that it can be accessed later by that name. In database terminology, named queries are called stored procedures. Database queries should be very easy when combining native queries (see the next section).

(iii) The local query

Instead of using a language with many restrictive entity queries, native queries allow the full use of SQL language directly from EJBS. Now it's possible to call Count (), Max () and other features directly on the database without having to do anything else.

(iv) Callback listeners

Callback listener, is an event listener, or, in database terms, a trigger. They support code invocation when an event occurs.

(v) Separation/re-attachment of objects

The ability to move from a Entitymanager control range and return to a sustainable storage is not possible until EJB version 3.0. Previously, in order to achieve this, the value from one object must be copied to a Pojo (normal Java object) and then copied back.

Before EJB 3.0, I always used the value-object and copied the value from the EJB into a pojo, and then used the object on the front end. If a value in the Pojo is changed, it will have to be "pushed back" to the EJB; This "chaos" state is no longer present. An object can even leave the JVM completely and return back at some later time and be attached again. The efficiency of this change cannot be underestimated.

(vi) O/R mapping type

The ability to map a field in an EJB directly to a column on a database is an EJB 3.0 that is difficult to implement before. This feature implementation has been less satisfying, and many third-party development tools have repeatedly postponed support for this functionality. One feature of my favorite xdoclet is that it can define which SQL type corresponds to each persistent field in my EJB. With the help of EJB 3.0 and annotation technology, we no longer need to use a third-party tool.

　　 Two, EJB 3.0 objects

It is noteworthy that the Enterprise Java Bean is now called Pojo. With the advent of annotation technologies, Java beans no longer require interface, home, and descriptor support files. This feature alone has won the favor of a large number of development teams for EJB 3.0.

Now that the enterprise objects are no longer locked into the application server, we no longer need to replicate them into and out of the Pojo, which allows developers to more easily display and edit the data stored in the EJB without having to differentiate the backend and front end of the application server. We will soon see the interesting effects of these changes on Xdoclet.

　　 Third, the conclusion

Although there is no doubt that EJB 3.0 is based on hibernate, it is, in fact, based on all top-level object/relational mapping tools. It appears that the tool is not a simple "modify" version of these tools, but in fact a brilliant "movie" Created by Sun. Instead of having developers learn a "new but functionally identical tool", developers simply need to take some time to upgrade to the new version of EJB 3.0, because EJB 3.0 is created based on tools they already know and love.