Summary on persistent context propagation of J2EE persistent layer (continued)

Source: http://yuquan-nana.javaeye.com/blog/296257

 

Keywords: propagation of persistent Context

Author: unrestrained
URL:Http://yuquan-nana.javaeye.com

>>>Reprinted please indicate the source!<

 

Next I will go to the previous article "Summary of J2EE transaction concurrency control policies". Today I will write about the propagation of persistent context.

Currently, the persistence layer framework has a concept of persistence context. Below we will summarize the concept of persistence context with popular Hibernate and JPA.

If we use OO to develop the system, we will implement business functions through fine-grained classes to reduce coupling and increase cohesion. This creates a problem, how to spread the persistence context in different classes (which is actually the repository in Dao or DDD), such as in the traditional development mode, when a service accesses the database through different Dao methods, how can we ensure that the session used in different Dao classes and the persistence context corresponding to the session are the same? This involves how persistent context is transmitted. The following describes Hibernate and JPA, which are familiar to me. In hibernate, different policies are required based on different underlying transactions:

1 propagation of persistent context in hibernate 1.1 JDBC transactions

At this time, Hibernate binds the current session to the current thread through threadlocal, so that as long as it is called in the same thread, the obtained session is the same, specifically configuring hibernate. the current_session_context_class attribute is thread, so that hibernate internally binds the session with the current thread through the implementation class threadlocalsessioncontext of the currentsessioncontext interface. When the getcurrentsession () method of sessionfactory is called, the returned session bound to the current thread solves the problem of persistent layer context propagation.

1.2 use JTA transactions

At this time, Hibernate binds the current session and the corresponding persistent context to the global JTA transaction, so that we can use the getcurrentsession () of sessionfactory () the method obtains the session bound to the current JTA transaction. specifically, configure the property hibernate. current_session_context_class is JTA. In this way, Hibernate internally binds the session with the current JTA global transaction through the implementation class jtasessioncontext of the currentsessioncontext interface. Therefore, when we use SF. when getcurrentsessioncontext () is used to obtain the session, the obtained session is bound to the current JTA.

However, in this case, you must pay special attention to one problem: you cannot use the transaction interface of Hibernate and getcurrentsession () at the same time, because the current session is bound to the global JTA transaction, if the session is passed. begintransaction () to start the transaction. This indicates that there was no transaction before. Since there was no transaction, how did we bind our session to the Global JTA transaction? Therefore, you must note that when using JTA transactions and using the getcurrentsession () method, do not use the native transaction interface of hive. However, if we use opensession (), we can use the native transaction interface of Hibernate to control JTA transactions.

Finally, you need to make it clear that there is another way to bind persistence context in hibernate, that is, by setting hibernate. the current_session_context_class attribute is managed. Inside hiberante, it is bound through the implementation class managedsessioncontext of the currentsessioncontext interface. In this case, the implementation of sessions in Hibernate is described below.

2. propagation of persistent context in JPA

In JPA, the propagation of persistent context varies according to different transaction models. The following is a description:

2.1 use the resource-local transaction model

If the resource-local transaction model is used, this is used with the support of non-J2EE application servers. Therefore, the lifecycle of our persistent context is bound to the current entitymanager. Therefore, we can spread the same entitymanager instance in different classes to spread the transaction context.

2.2 Use the JTA Transaction Model

Under this model, we have support for EJB containers. The propagation of persistent context is based on the transaction context, before explaining how to disseminate data, you must first define the lifecycle of two different transaction contexts in the EJB component:

For stateless Session Bean, the life cycle of the persistence context is consistent with that of the current system transaction, that is, the transaction-type persistence context of the stateless Session Bean. When the transaction ends, the persistence context is over, and all persistence objects are changed to detached ).

For statefull session beans, the life cycle of the persistent context is consistent with that of the current stateful Session Bean. Persistent context is disabled only when the stateful Session Bean is removed from the system, this is the extended transaction context of the stateful Session Bean.

After figuring out the lifecycles of these two different transaction contexts, let's talk about how persistent contexts are transmitted. The persistence context is transmitted through the current system transaction. When an EJB component calls another EJB component, if the transaction scope of the two EJB components is the same, the persistence context will be propagated, the following situations are described as follows:

Call between stateless session beans: If two stateless session beans are called in the same transaction, the persistence context is the same and is propagated through the current transaction.

Stateful Session Bean calls stateless Session Bean: in this case, if the two are in the same transaction, the extended transaction context of the stateful Session Bean will be transmitted to the stateless Session Bean, it is actually spread through transactions. However, if the called stateless session bean does not support transactions (the transaction attribute is not support or never ), at this time, the persistence context cannot be propagated (the JPA specification specifies that the extended persistence context cannot be propagated to the stateless session bean without transactions ).

Call between stateful session beans: No matter whether two stateful session beans support transactions or not, the extended persistent context will be propagated, instead of through system transactions, instead, it is spread through the instance of statefull Session Bean (however, it must be noted that the stateful Session Bean must be injected through the container or displayed through the JNDI lookup ).

Stateless Session Bean calls stateful Session Bean: A stateless session bean with a transaction scope persistent context calls a statefull Session Bean will cause an error because the current transaction context cannot be propagated)

In summary, persistent context propagation between ejbs is transmitted through our system transactions. If ejbs do not support transactions (the transaction attribute is set to not support or never )), the persistent context will not be transmitted, but the extended persistent context will be transmitted through the statefull Session Bean, even if there is no transaction, in the next article, we will talk about how to implement the session.

The above is about how persistence can spread between different classes in the persistence layer. In fact, it is actually spread through the current thread and the current system transaction, however, the extended persistent context with statefull Session Bean is spread through instances. In the following discussion about implementation sessions, I will also discuss this issue. When we have mastered the principles and encountered some problems, we will soon find a solution.

 

Not complete...

Next article "how to implement a session in the J2EE persistent layer"