You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Craig Russell (JIRA)" <ji...@apache.org> on 2007/08/07 20:49:59 UTC
[jira] Created: (OPENJPA-310) Rework ManagedRuntime to make better
use of TransactionSynchronizationRegistry
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
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.
[jira] Updated: (OPENJPA-310) Rework ManagedRuntime to make better
use of TransactionSynchronizationRegistry
Posted by "Safin Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Safin Li updated OPENJPA-310:
-----------------------------
Attachment: OPENJPA-310-patch.zip
this is my fixing for this issue
> 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
>
>
> 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.
[jira] Updated: (OPENJPA-310) Rework ManagedRuntime to make better
use of TransactionSynchronizationRegistry
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-310:
------------------------------------
Fix Version/s: (was: 1.1.0)
1.2.0
> 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.2.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.
[jira] Commented: (OPENJPA-310) Rework ManagedRuntime to make
better use of TransactionSynchronizationRegistry
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (OPENJPA-310) Rework ManagedRuntime to make better
use of TransactionSynchronizationRegistry
Posted by "Safin Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Safin Li updated OPENJPA-310:
-----------------------------
Attachment: OPENJPA-310.patch
Patrick,
I have attached the diff, would you please help to review it?
> 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.
[jira] Updated: (OPENJPA-310) Rework ManagedRuntime to make better
use of TransactionSynchronizationRegistry
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-310:
---------------------------------
Fix Version/s: (was: 1.2.0)
1.3.0
Moving to next release
> 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.3.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.
[jira] Commented: (OPENJPA-310) Rework ManagedRuntime to make
better use of TransactionSynchronizationRegistry
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563646#action_12563646 ]
Patrick Linskey commented on OPENJPA-310:
-----------------------------------------
Hi Safin,
The preferred way to attach a patch for review is to make the changes in your environment and run 'svn diff > OPENJPA-<issuenumber>.patch, and then attach that patch. This is easier than attaching the actual files because others can then examine the patch directly or apply the patch to their environments without having to extract anything. Could you attach a patch generated in that manner for review?
> 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
>
>
> 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.
[jira] Commented: (OPENJPA-310) Rework ManagedRuntime to make
better use of TransactionSynchronizationRegistry
Posted by "Safin Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563003#action_12563003 ]
Safin Li commented on OPENJPA-310:
----------------------------------
Hi, Craig,
I have fixed this issue according to your suggestion, basically, I move part logic of syncWithManagedTransaction(BrokerImpl broker, boolean begin) & findTransactionalBroker(String user, String pass) into ManagedRuntime.
Would you please help to review it?
Thanks
- Safin
> 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
>
>
> 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.