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
