2

Just a clarification on my understanding of how Container-Managed Transactions(CMTs) work in JPA -

CMTs spare the application the effort of beginning and committing transactions explicitly right?

CMTs can ONLY be applied to session and mesage-driven beans and NOT pojos?

My rationale for the above questions is - i'd like to know how to access an entity from a java-se application as well as a java-ee. Do i need two separate persistence unit?

Rodrigo Guedes
  • 1,169
  • 2
  • 13
  • 27
isaiah
  • 311
  • 2
  • 5
  • 14

2 Answers2

4

I allow myself to rewrite completely my answer cause it wasn't clear at all and worse, some things were simply wrongs.

The fact is that you (and I) are mixing EJB and JPA terminology.
JPA is only talking about entity beans. Session bean (including CMT and BMT) are part of the EJB spec.
In JPA we will talk about container-managed and application-managed entity manager linked to JTA or resource-local persitence unit.

Here are the relevant part of the JPA spec :

A container-managed entity manager must be a JTA entity manager. JTA entity managers are only specified for use in Java EE containers. An application-managed entity manager may be either a JTA entity manager or a resource-local entity manager.

[...]

Both JTA entity managers and resource-local entity managers are required to be supported in Java EE web containers and EJB containers. Within an EJB environment, a JTA entity manager is typically used. In general, in Java SE environments only resource-local entity managers are supported.

[...]

An entity manager whose transactions are controlled through JTA is a JTA entity manager. A JTA entity manager participates in the current JTA transaction, which is begun and committed external to the entity manager and propagated to the underlying resource manager.`

[...]

When a container-managed entity manager is used, the lifecycle of the persistence context is always managed automatically, transparently to the application, and the persistence context is propagated with the JTA transaction

So you will need to define 2 persistence unit only if you want to use a JTA (weather or not container-managed) entity manager in the java EE application.

Gab
  • 7,869
  • 4
  • 37
  • 68
  • How can a session bean not be part of a persistence unit? And what do you actually mean by that? Only entity beans are part of a persistence unit, aren't they? – bennidi Apr 05 '13 at 10:49
  • Also: transaction type RESOURCE_LOCAL/JTA is different from CMT /BMT – bennidi Apr 05 '13 at 10:57
  • 1
    right i confound both as i never used ejb alone, for me JTA datasource and CMT come together but it seems it's not the case cf. http://stackoverflow.com/questions/3217586/difference-between-a-jta-datasource-and-a-resource-local-datasource – Gab Apr 05 '13 at 12:08
1

CMT is defined declaratively using annotations that are evaluated by the Java EE container which will then provide the required transaction handling transparently. Pojos are not managed by a container, so no CMT can be applied.

As for your question about the entities. You should create a DAO layer to abstract away the technical details of your persistence logic. you can basically use one generic dao implementation to support JPA. This basically the only part that needs to be different for thw two environments. In a container you will get your transactions for free as defined in the annotations. If running in standard java se, you must begin/commit/rollback your transactions yourself.

I suggest that you create a generic dao implementation that defines transactions declaratively and expects to run inside a container. For use in java se you have a decorator for this dao that takes care of proper transaction handling to emulate what the container would actually do.

I think you don't really need to change anything in the persistence.xml but maybe I am wrong here

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
bennidi
  • 2,092
  • 21
  • 27