[ 
https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564822#action_12564822
 ] 

Patrick Linskey commented on OPENJPA-310:
-----------------------------------------

Craig: is your original comment suggesting that the TSR might ignore the 
passed-in map and do its own lookup to find the Broker (the Synchronization)?

> Rework ManagedRuntime to make better use of TransactionSynchronizationRegistry
> ------------------------------------------------------------------------------
>
>                 Key: OPENJPA-310
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-310
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.0.0
>            Reporter: Craig Russell
>            Priority: Minor
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-310-patch.zip, OPENJPA-310.patch
>
>
> This is the continuation of the TransactionSynchronizationRegistry issue 
> OPENJPA-295 that is now resolved.
> Looking at how to use the TSR map of object->object instead of the 
> _transactional, we would need to make a change to the AbstractBrokerFactory 
> method BrokerImpl findTransactionalBroker(String user, String pass). The 
> change would delegate to the ManagedRuntime which might have a better way to 
> look up the Broker in the context of the current transaction.
> The _transactional map is a map of TransactionKey to Broker. This is needed 
> for a completely different purpose (keeping track of whether there are any 
> Brokers with open transactions). 
> The issue is separation of concerns. Currently the ManagedRuntime doesn't 
> really know anything about Brokers or transaction maps. To implement the 
> findTransactionalBroker entirely in ManagedRuntime would introduce a lot of 
> broker-aware code. We could simply have ManagedRuntime know about a Map of 
> Transaction to Object, and do the rest of the processing in 
> AbstractBrokerFactory. This would separate functionality but not completely.
> With this separation, the ManagedRuntime would have a new method Object 
> getByTransactionKey(Object brokerFactory, Map transactional) that returns the 
> entry associated with the current transaction (which it knows how to get) in 
> the Map parameter (Abstract implementation) or the entry associated with the 
> TSR Map using the brokerFactory as the key. This is not completely abstract 
> but pretty close.
> But if we do all that, we should probably look at delegating most of the 
> syncWithManagedTransaction to the ManagedRuntime as well...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to