geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Transactions and DB Pools in JPA
Date Wed, 09 Aug 2006 00:19:32 GMT

On Aug 8, 2006, at 4:28 PM, Aaron Mulder wrote:

> OK, so for this JPA plugin, the goal is to support application-managed
> JPA for web apps.
>
> It looks like a JPA EntityManager has a call to getTransaction
> returning an EntityTransaction which you can used to begin and commit
> transactions in the non-JTA case (which, for now, let's assume this
> would be).
>
> So I'm thinking the code would look like this:
>
> EntityManager mgr = ...
> EntityTransaction tx = mgr.getTransaction();
> tx.begin();
> // save some JPA changes
> tx.commit();
>
> There was a comment that we shouldn't used Geronimo DB pools with JPA,
> which I don't follow.  What is the suggested way to hook the JPA
> provider up to the database?  It looks like you provide a
> PersistenceUnitInto with methods getJtaDataSource and
> getNonJtaDataSource...  I don't know which one of these a Geronimo DB
> pool would be.  Does it depend on whether the pool claims to support
> none, local, or XA transactions?

The basic rule is that for App-managed EntityManagers, the  
EntityManager needs a connection that is not an XA connection.  It  
also needs to own that connection for the life of the EntityManager  
(more or less).  Basically, it needs to get a connection and be able  
to turn auto commit off, issue any begin tx and commit tx sql  
statements on it, and do it's caching/flushing accordingly.  It does  
all the work and does not cooperate with anyone.

So if you could hook the EntityManager up with a non-XA connection  
that it can hold onto forever (at least for as long as it want's to  
hold it open), then you should be fine.  But it sounded like you were  
saying that XA transactions would come for free if you simply hooked  
the EntityManager up to the transaction managed db pool, which would  
be bad.  It that point, it's pretty much the EntityManager itself you  
need to pool and track with the transaction as you would any other XA  
enabled resource.

> Also, I guess I need to figure out whether we could be in the JTA case
> -- I'm not sure if supplying a JTA DataSource is enough.  Maybe then
> the code would look like this:
>
> UserTransaction tx = ...
> tx.begin();
> // save some JPA changes
> tx.commit();
>

This is the whole container-managed EntityManager scenario, which as  
I mention above is another thick set of rules.  Here users do not get  
to create the EntityManager via the EntityManagerFactory in JNDI, nor  
do they get to use the EntityTransaction.  Instead the EntityManager  
itself is in JNDI and there is no EntityManagerFactory in JNDI.  When  
they lookup the EntityManager from JNDI, they get the one associated  
with the current transaction, or a new EntityManager that now becomes  
enrolled in the transaction.  There's more to it than that, but  
that's the basic idea.

-David


Mime
View raw message