JPA implementation issues

[Dewei]

I am having some doubts for my current project in J2SE (Swing). There are two questions involved the use of JPA (Toplink) to the relevant tutorials gave none or only contradictory answers.

1. If EntityManager usually 1x per application or when required, that is instantiated multiple times?
2. The difference between persist () and merge () is where I clear but is also the exclusive use of function merge (). Is that really so or there are counter-arguments?

I need your help. Please help me immediately.

[Mecurtis]

1. If EntityManager usually 1x per application or when required, that is instantiated multiple times?

A lot! EntityManager is similar to a Hibernate Session, if this concept is known.
Per "work unit" is used an EntityManager, either per transaction or for multiple
technically related transactions (PersistenceContextType.EXTENDED). In any case, the EM is not thread-safe!

2. The difference between persist () and merge () is where I clear but is also the exclusive use of function merge (). Is that really so or there are counter-arguments?

Merge () is similar to Hibernate saveOrUpdate (), so you can actually merge with also create new entities. I guess the only difference is in the propagation of relevant events (or CascadeType.MERGE.PERSIST). Merge () you need only entities but also for working with detached. I avoid the as far as possible, changes to (attached) entities made so automatically.

[Adley]

I would like to tell that persist to second is used to announce the initial needs of an entity. Can be (that also works at the merge point, I've never tried ). merge () reattacht an entity is a EntityManager. This is in particular in the JEE Web environment necessary if a session manager (eg Seam) holds the data objects over a session of Entitiymanager but not retained on request limits.

[pancham]

Per "work unit" is used an EntityManager, either per transaction or for multiple technically related transactions (PersistenceContextType.EXTENDED). In any case, the EM is not thread-safe!

Very true. It should be stressed here is that the statement refers to non-managed environments (ie in the event that you generated EMF and EM programmatically). Can you can inject themselves the EM of a Appserver or jumping to use this threadsafe.

[PARRISH]

I think that the "Mecurtis" is correct. This helps to understand something maybe necessary to step on. The EM defines a Persistence context yes, that is a virtual set of persistent entities. Persist takes now one has not, in this context existing in those same entity. This generally results in an insert to the DB. A merge merged just changes back to an entity in the Persistence context. This results in most cases to an update (in case that there are changes), but can also simply do nothing (if there are no changes to merge).

[Umberto-Micro]

It is a special feature of Spring that is produced here per thread a EM, otherwise it is also in a J2EE container that an EM can be used by multiple threads. An entity manager may not be shared among multiple concurrently executing threads. Entity may only be accessed in a single-threaded manner. If the EM is injected into stateless session beans, which of course solves the problem, but as would have to be careful in a servlet!!

[Ransom]

I would like to again suspend it in the discussion. I'm currently working up a small RCP application and a set EclipseLink as persistence (since this is also present in OSGI-bundles and can be used directly for the RCP). The statement above, you need "very many EntityManager" very confused myself now. I thought the EM is the Object Cache, and was of the opinion that these monitors my objects. create an EM I expected very expensive to build (similar to a whole new DB connection). In EclipseLink mailing list, I received a tip that there are basically two ways to use JPA in desktop applications:

1. A global EM (this was my first approach),
2. Several EM, on a per application window.

The window approach seems complicated in the sense which EM is responsible for which classes. Furthermore, I want to use against the JPA Tutorials, DAOs because thus are only my model and my data-dependent plugin JPA / EclipseLink. The plugins operate with the business logic of the DAOs. Regarding transactions, I thought of two methods in the abstract (generic) DAO superclass, with whom I can start by committing transactions. But that's probably not as clean as it can occur as the CustomerDao started a transaction, the last steps but executed by another DAO which then completes the transaction.

[Solitario]

Creating an EM is expensive, but still more expensive is the long lifetime of there. In the web area you keep an EM is not more than one request (Even that is sometimes too long). In an RCP application, you have to thoughts on the life cycle of EMs do. (I speak mainly about Hibernate-based EMs).