[JBoss JIRA] (CDI-520) 3.6. Java EE components
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-520:
--------------------------------------
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..
The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.
EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}
The EJB container use the _transaction manager_ to control transaction demarcation.
JTA 1.2, §3.2:
{quote}
**For example**, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread’s transaction context.
{quote}
JTA 1.2, §3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.
This interface is implemented by the application server as a stateless service object. The same object can be used **by any number of components** with complete thread safety.
{quote}
The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityMan...]", may be retrieved using {{EntityManager.getDelegate()}}.
Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.
JTA 1.2 §1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.
\[..]
A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}
JTA 1.2 §2.1:
{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}
JTA 1.2 §3.7:
{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}
The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.
I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.
It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?
Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.
> 3.6. Java EE components
> -----------------------
>
> Key: CDI-520
> URL: https://issues.jboss.org/browse/CDI-520
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.1.Final
> Reporter: Martin Andersson
> Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
