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
>>
>>
>>
>
|