On 10/28/2011 05:48 PM, Linda DeMichiel wrote:
> IIRC correctly, the reason the platform added the
> TransactionSynchronizationRegistry
> was so that access to the TransactionManager wouldn't be needed. This
> issue was discussed
> in the Java EE 5 expert group, where there was some strong opposition to
> exposing
> the TransactionManager itself-- which led to the introduction of
> TransactionSynchronizationRegistry.
>
> Why isn't this sufficient?
For the JPA 2.0 persistence providers, some of them use the
TransactionSynchronizationRegistry and some don't (as best I could tell
with viewing their jar dependencies from
http://www.jboss.org/tattletale). Of the JPA 2.0 providers that don't
support the TransactionSynchronizationRegistry, they seem to contain
application server vendor specific ways of getting the
TransactionManager. Of the persistence providers that support using the
TransactionSynchronizationRegistry, they also support use of the
TransactionManager (which can be useful for getting the current
Transaction).
The current Transaction gives a way to register a session
synchronization. Registering session (non-interposed) synchronizations
might be useful for some providers as way to have some extension code
execute before the interposed synchronizations run. By the JTA
specification, that is the only ordering that can be expected (no
ordering within session synchronizations or within interposed
synchronizations). Some JTA implementations actually do order within
the session synchronizations/interposed synchronizations (to provide a
higher quality of service).
For JPA 2.1, should we ban use of TransactionManager in persistence
providers but also offer an instance of a wrapper class for registering
session synchronizations class RegisterSessionSynchronization { void add
(Synchronization) } that could be passed to persistence providers (if we
find its needed)?
I would like to ask another broader question. What is the impact on
application servers that have switched to using
TransactionSynchronizationRegistry that want to use JPA 1.0 or 2.0
persistence providers that only use SessionSynchronization
(TransactionManager)? I think that is actually okay, since the
persistence providers session synchronization runs first (gets a
database connection which registers a non-interposed sync). I think
what doesn't work, is when the persistence provider only supports the
TransactionSynchronizationRegistry and the application server uses
session synchronizations (when the provider interposed synchronziation
attempts to get a db connection, the db pool manager will attempt to
register a session synchronization which is illegal).
In summary, I would like to work towards improving pluggability and
especially avoiding the need for vendor specific integration code in
persistence providers.
Scott
>
> On 10/28/2011 2:33 PM, Scott Marlow wrote:
>> On 10/28/2011 01:57 PM, Linda DeMichiel wrote:
>>> The Java EE platform requires that the
>>> TransactionSynchronizationRegistry be made
>>> available through JNDI (or by injection). Doesn't this work? See section
>>> EE.5.11.
>>
>> Good point, the TransactionSynchronizationRegistry could be looked up
>> via JNDI.
>>
>> I think passing the TransactionManager JNDI name (or instance), to the
>> persistence provider would still be helpful, to
>> eliminate the application server specific code for obtaining the
>> TransactionManager.
>>
>>>
>>> -Linda
>>>
>>> On 10/28/2011 6:33 AM, Scott Marlow wrote:
>>>> Recently, I have been spending a lot of time on the JBoss AS JPA
>>>> container and its integration with persistence
>>>> providers using the JPA SPIs. I think we have some low hanging fruit
>>>> to be had, in standardizing how the persistence
>>>> providers obtain a JTA transaction manager.
>>>>
>>>> I've looked at (mostly four) different persistence providers and how
>>>> they have application server vendor (often version)
>>>> specific integration for obtaining either the JTA TransactionManager
>>>> or TransactionSynchronizationRegistry.
>>>>
>>>> To improve how persistence providers integrate with containers, I
>>>> think we should introduce properties for the container
>>>> to pass a TM/TSR reference to the provider. This will help reduce the
>>>> amount of application server vendor specific code,
>>>> needed by the different persistence providers.
>>>>
>>>> Perhaps the properties could be:
>>>>
>>>> javax.persistence.transactionmanager - JNDI name of JTA Transaction
>>>> Manager or instance of JTA Transaction Manager
>>>>
>>>> javax.persistence.transactionsynchronization - JNDI name of
>>>> TransactionSynchronizationRegistry or instance of
>>>> TransactionSynchronizationRegistry.
>>>>
>>>> The idea being that providers should expect either a TM/TSR to be
>>>> passed directly or to use a JNDI lookup name (so
>>>> providers could work with EE servers that don't have a single TSR/TM
>>>> to pass in but perhaps have several instances to
>>>> choose from).
>>>>
>>>> What do you think?
>>>>
>>>> Scott
>>