Warum unterschiedliche Persistenzeinheiten mit getrennten Datenquellen die gleiche Datenquelle abfragen?

Container Managed Persistence Contexts

Wenn mit container-managed Persistenz-Kontexte (wie Sie über @PersistenceContext-Annotationen), die JPA-Spezifikation legt fest, dass nur EIN persistenzkontext zugeordnet werden kann mit einer JTA-Transaktion.

Den Persistenz-Kontext wird erstellt, indem die Java-EE-container. Trotz Auftritten der code (@PersistenceContext-Annotationen scheinen zu behaupten, dass PC injiziert wird direkt in die EntityManager Instanz-Variablen), die Persistenz-Kontext wird gespeichert als Referenz INNERHALB DER JTA-TRANSAKTION. Jedes mal, wenn ein EntityManager Betrieb tritt es nicht auf eigene interne Persistenz-Kontext. Stattdessen tut es eine spezielle operation, weil es container-managed - es sieht immer up der persistence context in die JTA-Transaktion und verwendet. Dies wird als JTA-Persistenz Kontext-propagation.

Einige Zitate aus der JPA Spezifikation:

Wenn ein container-managed entity-manager verwendet wird, wird der Lebenszyklus der
Persistenz-Kontext wird immer automatisch verwaltet, transparent
die Anwendung und der Persistenz-Kontext weitergegeben wird, mit der
JTA-Transaktion.

Container-managed Transaction-scoped Persistence Context

...
Eine neue Persistenz-Kontext beginnt, wenn der container-managed entity-manager
aufgerufen wird[76] im Rahmen einer aktiven JTA-Transaktion, und es ist
keine aktuellen persistenzkontext bereits im Zusammenhang mit der JTA
die Transaktion. Der Persistenz-Kontext erstellt und dann verknüpft
mit der JTA-Transaktion.

Container-managed Erweiterten Persistenz-Kontext

...
Ein container-managed erweiterten Persistenz-Kontext kann nur dann eingeleitet werden, im Rahmen
ein stateful session-bean. Es besteht ab dem Punkt, an dem die stateful session-bean
das deklariert eine Abhängigkeit von einem entity manager vom Typ PersistenceContextType.ERWEITERT
ist erstellt, und es wird gesagt, an die stateful session-bean. Die Abhängigkeit von der
extended persistence context ist erklärt durch den PersistenceContext-annotation-oder persistence-context-ref-deployment-descriptor-element.
Der persistenzkontext geschlossen wird der container, wenn die @Remove Methode des stateful session bean abgeschlossen ist (oder die stateful session-bean-Instanz wird sonst zerstört).

Anforderungen für die Persistenz Kontext-Propagation

... Wenn eine Komponente aufgerufen wird, und es gibt keine JTA-Transaktion ..., der persistenzkontext wird nicht weitergegeben.
• Aufruf einer entity-manager definiert mit PersistenceContext-
Typ.TRANSAKTION entsteht ein neues Persistenz-Kontext.
• Aufruf einer entity-manager definiert mit PersistenceContext-
Typ.ERWEITERT wird das Ergebnis in der Nutzung der vorhandenen extended persistence context
gebunden an diese Komponente.

... Wenn eine Komponente aufgerufen wird und die JTA-Transaktion weitergegeben wird in die Komponente:
• Wenn die Komponente eine stateful-session-bean, die einen erweiterten Persistenz-Kontext gebunden wurde, und es ist ein anderes Persistenz-Kontext gebunden an die JTA-Transaktion, wird eine EJBException geworfen wird durch den container.
• Andernfalls, wenn es einen Persistenz-Kontext gebunden an die JTA-Transaktions -, Persistenz-Kontext weitergegeben und verwendet werden.

So ist das dein problem.
Die offensichtliche $64-Frage: WARUM funktioniert die Skillung Fragen???

Gut, es ist, weil es eine bewusste trade-off, das bringt leistungsstarke EntityManager Magie zu EJBs.

Verwendung von JTA-Transaktionen zu propagieren einer einzigen Persistenz-Kontext hat eine Einschränkung: Transaktionen können nicht überspannen mehrere Persistenz-Kontexte, so kann nicht überspannen mehrere Datenbanken.

Aber es hat auch einen unschätzbaren Vorteil: jeder entityManager erklärt in EJBs können automatisch teilen die gleichen persistence context und damit arbeiten können auf den gleichen Satz von JPA-Entitäten und nehmen Sie in der gleichen Transaktion. Sie können eine Kette von EJBs aufrufen von anderen EJBs von beliebiger Komplexität, und Sie alle Verhalten sich vernünftig und konsequent gegen die JPA-entity-Daten. Und Sie brauchen auch nicht die Komplexität der konsequent letzteres/sharing-entity manager-Bezüge über Methodenaufrufe - die EntityManagers erklärt werden kann privat in jeder Methode. Die Logik kann ganz einfach sein.

Die Antwort Auf Dein Problem: mit Application-Managed Persistence Contexts (per application-managed EntityManagers)

Erklären entityManager über einen dieser Ansätze:

//"Java EE style" declaration of EM
@PersistenceUnit(unitName="H2PU")
EntityManagerFactory emfH2;
EntityManager emH2 = emfH2.createEntityManager();

ODER

//"JSE style" declaration of EM
EntityManagerFactory emfH2 = javax.persistence.Persistence.createEntityManagerFactory("H2PU");
EntityManager emH2 = emfH2.createEntityManager();

and the same for emfOracle & emOracle.    

Rufen Sie em.close (), wenn Sie fertig sind mit jedem EM - prefereably über ein final { } - Klausel oder über eine Java 7 try-with-resources statement.

Application-managed-EMs noch teilnehmen (d.h. synchronisiert mit) JTA-Transaktionen. Eine beliebige Anzahl von application-managed-EMs teilnehmen kann, in einem einzigen JTA Transaktion - aber keiner von beiden wird jemals Ihre Persistenz Kontext zugeordnet oder weitergegeben an irgendwelche container managed EM.

Wenn der EntityManager erstellt wird, die außerhalb des Kontexts einer JTA-Transaktion (bevor die Transaktion begonnen hat), dann müssen Sie Fragen es ausdrücklich beitreten die JTA-Transaktion:

//must be run from within Java EE code scope that already has a JTA 
//transaction active:
em.joinTransaction();  

Oder noch einfacher, wenn der EntityManager ist erstellt im Kontext einer JTA-Transaktion, dann die application-managed EntityManager automatisch verbindet die JTA-Transaktion implicity - keine joinTransaction() benötigt.

Also Application-managed-EMs kann eine JTA-Transaktion umfasst mehrere Datenbanken. Natürlich, Sie können immer ausführen einer lokalen Ressource JDBC Transaktion unabhängig von JTA:

EntityTransaction tx = em.getTransaction();  
tx.begin();

//....

tx.commit();

EDIT: ZUSÄTZLICHE DETAILS für die Transaktion-Management mit Application-Managed Entity-Manager

WARNUNG: die folgenden Codebeispiele sind für den schulischen Einsatz - ich hab Sie eingetippt aus der Spitze von meinem Kopf zu erklären meine Punkte & hatte noch keine Zeit ihn zu kompilieren/Debuggen/testen.

Den Standard @TransactionManagement parameter für EJBs ist TransactionManagement.CONTAINER-und Standard - @TransactionAttribute parameter für EJB-Methoden ist TransactionAttribute.ERFORDERLICH.

Gibt es vier Permutationen für Transaktions-management:

• A) EJB CONTAINER verwaltet JTA-Transaktionen

  Dies ist die bevorzugte Java-EE-Ansatz.
  
  EJB-Klasse @TransactionManagement Anmerkung:
  
  eingestellt werden müssen, um TransactionManagement.CONTAINER explizit oder auslassen, es zu verwenden implizit den default-Wert.
  
  EJB-Methode, die @TransactionAttribute annotation:
  eingestellt werden müssen, um TransactionAttribute.ERFORDERLICH, ausdrücklich oder lassen Sie es zu implicity verwenden Sie den Standardwert. (Hinweis: wenn Sie noch eine andere business-Szenario, die Sie nutzen könnten TransactionAttribute.OBLIGATORISCHE oder TransactionAttribute.REQUIRES_NEW, wenn Ihre Semantik Ihre Bedürfnisse abgestimmt ist.)
  
  Application-managed entity-Manager:
  
  Sie müssen erstellt werden, über die Persistenz.createEntityManagerFactory("unitName") und emf.createEntityManager(), wie oben beschrieben.
  
  Join the EntityManagers mit der JTA-Transaktion:
  
  Erstellen des EntityManagers INNERHALB einer Transaktion EJB-Methode und Sie werden automatisch an die JTA-Transaktion. ODER wenn EntityManagers sind angelegt, Anruf-em.joinTransaction() innerhalb einer Transaktion EJB-Methode.
  
  Rufen Sie EntityManager.close (), wenn Sie fertig sind mit Ihnen.
  Das sollte alles sein, was erforderlich ist.

  Basic-Beispiele - verwenden Sie einfach mehr EntityManagers für eine Transaktion über mehrere Datenbanken:

  @Stateless  
  public class EmployeeServiceBean implements EmployeeService {
  
      //Transactional method
      public void createEmployee() {
          EntityManagerFactory emf = Persistence.createEntityManagerFactory("EmployeeService");
          EntityManager em = emf.createEntityManager();
          Employee emp = ...; //set some data
          //No need for manual join - em created in active tx context, automatic join:
          //em.joinTransaction();         
          em.persist(emp);
          //other data & em operations ...
          //call other EJBs to partake in same transaction ...
          em.close();    //Note: em can be closed before JTA tx committed. 
                     //Persistence Context will still exist & be propagated 
                     //within JTA tx.  Another EM instance could be declared and it 
                     //would propagate & associate the persistence context to it.
                     //Some time later when tx is committed [at end of this 
                     //method], Data will still be flushed and committed and 
                     //Persistence Context removed .
      emf.close();
      }
  
  }
  
  
  
  @Stateful  
  public class EmployeeServiceBean implements EmployeeService {  
  
      //Because bean is stateful, can store as instance vars and use in multiple methods  
      private EntityManagerFactory emf;
      private EntityManager em;
  
      @PostConstruct      //automatically called when EJB constructed and session starts
      public void init() {
          emf = Persistence.createEntityManagerFactory("EmployeeService");
          em = emf.createEntityManager();
      }
  
      //Transactional method
      public void createEmployee() {
          Employee emp = ...; //set some data
          em.joinTransaction();         //em created before JTA tx - manual join
          em.persist(emp);
      }
  
      //Transactional method
      public void updateEmployee() {
          Employee emp = em.find(...);  //load the employee
          //don't do join if both methods called in same session - can only call once: 
          //em.joinTransaction();         //em created before JTA tx - manual join
          emp.set(...);                 //change some data
                               //no persist call - automatically flushed with commit
      }
  
      @Remove                           //automatically called when EJB session ends
      public void cleanup() {
          em.close();
          emf.close();
      }
  //...
  }

• B) EJB mit BEAN-managed-JTA-Transaktionen

  @TransactionManagement.BEAN.
  
  Injizieren der JTA UserTransaction Schnittstelle, so dass die bean kann direkt daneben JTA-Transaktionen.
  
  Manuell zu markieren/zu synchronisieren, die Transaktion über UserTransaction.begin()/commit()/rollback().
  
  Sicherstellung der EntityManager schließt sich der JTA Transaktion - entweder erstellen Sie die EM in einer aktiven JTA-Transaktions-Kontext ODER rufen Sie em.joinTransaction().

  Beispiele:

  @TransactionManagement(TransactionManagement.BEAN)  
  @Stateless  
  public class EmployeeServiceBean implements EmployeeService {
  
      //inject the JTA transaction interface
      @Resource UserTransaction jtaTx;
  
      public void createEmployee() {
          EntityManagerFactory emf = Persistence.createEntityManagerFactory("EmployeeService");
          EntityManager em = emf.createEntityManager();
          try {
              jtaTx.begin();
              try {
                 em.joinTransaction();         
                 Employee emp = ...; //set some data
                 em.persist(emp);
                 //other data & em operations ...
                 //call other EJBs to partake in same transaction ...
              } finally {
                  jtaTx.commit();
              }
          } catch (Exception e) {
             //handle exceptions from UserTransaction methods
             //...
          }
  
          Employee emp = ...; //set some data
          //No need for manual join - em created in active tx context, automatic join:
          //em.joinTransaction();         
          em.persist(emp);
          em.close();    //Note: em can be closed before JTA tx committed. 
                     //Persistence Context will still exist inside JTA tx.
                     //Data will still be flushed and committed and Persistence 
                     //Context removed some time later when tx is committed.
          emf.close();
      }
  
  }

• C) POJO/Nicht-EJB-mit hand-codiert (bean managed) - resource-local transactions (nicht JTA)

  Verwenden Sie einfach die JPA EntityTransaction-Schnittstelle für tx-Abgrenzung (die über em.getTransaction()).

  Beispiel:

  public class ProjectServlet extends HttpServlet {
  
      @EJB ProjectService bean;
  
      protected void doPost(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {
          //...
          try {
              EntityManagerFactory emf = Persistence.createEntityManagerFactory("myPU");
              EntityManager em = emf.createEntityManager();
              EntityTransaction tx = em.getTransaction();
              tx.begin();
              try {
                  bean.assignEmployeeToProject(projectId, empId);
                  bean.updateProjectStatistics();
              } finally {
                  tx.commit();
              }
          } catch (Exception e) {
             //handle exceptions from EntityTransaction methods
             //...
          }
      //...
      }
  }

• D) POJO/Nicht-EJB-mit hand-codiert (POJO-managed) JTA-Transaktionen

  Dieser übernimmt die POJO/Bauteil ausgeführt wird, in einige container, JTA unterstützen.
  
  Wenn in einem Java EE-container, können Java EE-Ressource Injektion von JTA-UserTransaction-Schnittstelle.
  
  (Alternativ kann explizit lookup ein handle für die JTA-Schnittstelle und Abgrenzung tun, dann rufen Sie em.getTransaction().joinTransaction() - siehe JTA-spec.)

  Beispiel:

  public class ProjectServlet extends HttpServlet {
  
      @Resource UserTransaction tx;
      @EJB ProjectService bean;
  
      protected void doPost(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {
          //...
          try {
              tx.begin();
              try {
                  bean.assignEmployeeToProject(projectId, empId);
                  bean.updateProjectStatistics();
                  EntityManagerFactory emf = Persistence.createEntityManagerFactory("myPU");
                  EntityManager em = emf.createEntityManager();
                  //Should be able to avoid explicit call to join transaction.
                  //Should automatically join because EM created in active tx context.
                  //em.joinTransaction();
                  //em operations on data here
                  em.close();
                  emf.close();
              } finally {
                  tx.commit();
              }
          } catch (Exception e) {
             //handle exceptions from UserTransaction methods
             //...
          }
      //...
      }
  }

InformationsquelleAutor der Antwort