On Aug 8, 2006, at 2:02 PM, David Jencks wrote:
On Aug 8, 2006, at 1:43 PM, David Blevins wrote:
Yeah, not targeting container-managed JPA support with this plugin.
We are using a Geronimo DB pool for persistence, though. So doesn't
that mean it would be included in any transaction that was going on
already? Not too relevant for web apps, but would JPA in a Session
Bean inherit the Session Bean transaction settings? I'm not sure at
what point in the process the DataSource or Connection notices that
there's a transaction going on and enlists itself.
You probably don't want to do that. That would only work if the
Persistence provider did zero caching. You really can't go
swapping out the connections underneath an EntityManager that
caches. It is relevant to webapps too as they are allowed to
create an EntityManager from the EntityManagerFactory, call begin
transaction on it, shove it in to the Session, and pull it out at
a later request and call commit on it.
I'm don't understand the tx support in jpa yet. To get container
managed to work you definitely need the new tx manager interface to
get the cache flushed. Maybe theres a way to explicitly flush the
jpa cache in which case you could use UserTx around the whole
thing. If jpa can actually control tx itself you should be using a
no-tx db pool.
The EntityManager has methods on it to get something like a user
transaction which under the covers should start transactions and
flush caches accordingly. That's only usable in an Application-
Managed JPA scenario which is identical to the concept of a local
transaction. For Container-Managed JPA you're looking at something
very much like a Resource Adapter -- you proxy it from the user, keep
their reference hooked up the the actual reference in the current
transaction, and workout tx boundaries with the underlying provider.
-David
thanks
david jencks
-David
