gonzao_diaz wrote:
What is a "persistence unit"?
eh, come on, gonzao, you know it!
In JPA, you define your persistent units in "persistence.xml" like this:
Code:
<persistence-unit name="dpjw">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/dpjwDS</jta-data-source>
<mapping-file>META-INF/orm_dpjw.xml</mapping-file>
<class>org.dpjw.base.domain.Check</class>
(...)
</persistence-unit>
<persistence-unit name="dpjw_office">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/dpjw_office</jta-data-source>
<mapping-file>META-INF/orm_dpjw_office.xml</mapping-file>
<class>org.dpjw.base.domain.Bank</class>
(...)
</persistence-unit>
In your entities, you describe per annotation, to which persistent units they belong; i.e:
Code:
@Entity
@Table(name="BANK", schema="dpjw_office")
So, as in this example, I have to 2 persistent units, referring to 2 different databases (or database schemas).
My experience with this situation was:
- The transaction manager of JBoss, where my JPA app is running on, threw an exception complaining that the datasources I am using, that is: the JDBC driver (here: MySQL), is not capable of taking part in a 2 phase commit scenario.
- I had to resort to some code trying to manual emulate a 2PC: which isn't save. This means: I annotated an EJB which handles the other datasource with
Code:
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
Then I could invoke methods on that EJB from a transaction method of the EJB connected to the first datasource.
As I said: this is not save enough. If the inner transaction (created with REQUIRES_NEW) succeeds and commits, and the outer transaction fails, you would have to manually reset the results of the inner transaction; you cannot rollback it anymore.
So, a much better way is to split the application into separate processes with services operating on just one datasource, and then calling a service on the other application which has it's own transaction processing.