Difference between database connection through session bean and entity bean

What is the difference between writing JDBC (or) HIBERNATE Connectivity code in EJB3 Session Bean and writing same connectivity code through EJB3 Entity Bean(JPA). Could anyone please clarify this..

Both allow you to write Java that gets data in and out of databases, but the actual coding is very different.

JDBC lets you write SQL code

 INSERT INTO  ...

or

 SELECT  ... WHERE

You then have to write your own code to transfer data between your Java objects and the JDBC code. You end up with lots of repetive "put this field in that column" kind of code.

Have a look at examples such as link text to get a flavour.

In JPA/Hibernate you simply annotate your Java class with instructions about which tables and columns the fields correspond to. Greatly reduces the amount of code you need to write.

It's as simple as this example (taken from this JPA example:

@Entity
public class Inventory {
    @Id
    protected long id;
    ...
    public void setItem(Item item) {
        this.item = item;
        this.id = item.getSKU();
    }
    ...
}

I would say that Session Bean + JPA is considerably less effort than Session Bean + JDBC.

The EJB specification supports both transient and persistent objects. A transient object is referred to as a session bean, and a persistent object is known as an entity bean.

  A Session Bean

A session bean is an EJB that is created by a client and usually exists only for the duration of a single client-server session. A session bean usually performs operations such as calculations or database access on behalf of the client. While a session bean may be transactional, it is not recoverable if a system crash occurs. Session bean objects can be stateless or they can maintain a conversational state across methods and transactions. If a session bean maintains a state, the EJB container manages this state if the object must be removed from memory. However, persistent data must be managed by the session bean object itself.

The tools for a container generate additional classes for a session bean at deployment time. These tools obtain information from the EJB architecture by examining its classes and interfaces. This information is utilized to generate two classes dynamically that implement the home and remote interfaces of the bean. These classes enable the container to intercede in all client calls on the session bean. The container generates a serializable Handle class as well, which provides a way to identify a session bean instance within a specific lifecycle. These classes can be implemented to perform customized operations and functionality when mixed in with container-specific code.

In addition to these custom classes, each container provides a class that provides metadata to the client and implements the SessionContext interface. This provides access to information about the environment in which a bean is invoked.

An Entity Bean

An entity bean is an object representation of persistent data maintained in a permanent data store such as a database. A primary key identifies each instance of an entity bean. Entity beans are transactional and are recoverable in the event of a system crash.

Entity beans are representations of explicit data or collections of data, such as a row in a relational database. Entity bean methods provide procedures for acting on the data representation of the bean. An entity bean is persistent and survives as long as its data remains in the database.

An entity bean can be created in two ways: by direct action of the client in which a create() method is called on the bean’s home interface, or by some other action that adds data to the database that the bean type represents. In fact, in an environment with legacy data, entity objects may exist before an EJB is even deployed.

An entity bean can implement either bean-managed or container-managed persistence. In the case of bean-managed persistence, the implementer of an entity bean stores and retrieves the information managed by the bean through direct database calls. The bean may utilize either Java Database Connectivity (JDBC) or SQL-Java (SQLJ) for this method. (Session beans may also access the data they manage using JDBC or SQLJ.) A disadvantage to this approach is that it makes it more difficult to adapt bean-managed persistence to alternative data sources.

In the case of container-managed persistence, the container provider may implement access to the database using standard APIs. The container provider can offer tools to map instance variables of an entity bean to calls to an underlying database. This approach makes it easier to use entity beans with different databases.