[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3340?page=c...
]
Brian Stansberry updated HHH-3340:
----------------------------------
Description:
MultiplexingCacheInstanceManager.configureTransactionManager() throws an exception if it
finds the tm it's been passed doesn't match the one configured with the cache.
That needs to be removed. With JBossTS at least, if you do two lookups of the same JNDI
name you will get two distinct TransactionManager instances, both of which delegate to the
underlying TM. An equals() check on those instances will return false, causing
configureTransactionManager() to incorrectly throw the exception.
This check didn't exist in the previous JBC integration, and since it's
problematic I'm just going to convert the exception to a DEBUG log msg.
was:
MultiplexingCacheInstanceManager.configureTransactionManager() throws an exception if it
finds the tm it's been passed doesn't match the one configured with the cache.
That needs to be removed. With JBossTS at least, if you do two lookups of the same JNDI
name you will get two distinct TransactionManager instances, both of which delegate to the
underlying TM. An equals() check on those instances will return false, causing
configureTransactionManager() to incorrectly throw the exception.
This check didn't exist in the previous JBC integration, and since it's
problematic I'm just going to convert the exception to an INFO log msg.
Get rid of TransactionManager compatibility check in
MultiplexingCacheInstanceManager
-------------------------------------------------------------------------------------
Key: HHH-3340
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3340
Project: Hibernate3
Issue Type: Sub-task
Affects Versions: 3.3.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.3.0
MultiplexingCacheInstanceManager.configureTransactionManager() throws an exception if it
finds the tm it's been passed doesn't match the one configured with the cache.
That needs to be removed. With JBossTS at least, if you do two lookups of the same JNDI
name you will get two distinct TransactionManager instances, both of which delegate to the
underlying TM. An equals() check on those instances will return false, causing
configureTransactionManager() to incorrectly throw the exception.
This check didn't exist in the previous JBC integration, and since it's
problematic I'm just going to convert the exception to a DEBUG log msg.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira