[jbosscache-dev] Re: ComponentRegistry and TransactionManager

[Brian Stansberry]

Manik Surtani wrote:
> Brian
> 
> This is a bug in the ComponentRegistry.  The way it works at the moment, 
> when we start(), we recreate any components where construction differs 
> based on configuration, such as the interceptor chain and node factory.  
> the TM should be there as well - will patch this up and check it into 
> trunk.
> 

Thanks for the quick work!

The way I interpret this, sounds like it will try to resolve the TM 
twice -- once during bootstrap, and again in start()?  If so, can we 
avoid an ERROR logging during bootstrap? (This happens when OL is 
configured.)

> Cheers
> Manik
> 
> 
> On 10 Jan 2008, at 18:39, Brian Stansberry wrote:
> 
>> Interesting change from the ComponentRegistry has bitten me in the ass.
>>
>> The resolution of the TransactionManager used to take place in 
>> CacheImpl.create(), now it's happening via 
>> DefaultCacheFactory.bootstrap() -- i.e. as part of cache construction.
>>
>> This causes problems with the Hibernate integration, which injects the 
>> TM it knows about into the RuntimeConfig of the already-existing 
>> cache, before it calls create().  But that's too late -- the 
>> TransactionManagerFactory has already logged an error about a missing TM.
>>
>> A solution would be for Hibernate to get a Configuration first, inject 
>> the TM, and then build the cache.  But the CacheManager API doesn't 
>> expose a good way to do that.  An external caller can't modify the 
>> registered configurations.
>>
>> So:
>>
>> 1) What do you think about changing the ConfigurationRegistry API to 
>> allow some sort of updating of registered configurations?
>>
>> 2) In general, do you think it's a problem that we are now resolving 
>> things earlier in the process than we used to?  Other users may also 
>> be doing things programatically after cache construction but before 
>> create/start.
>>
>> -- 
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com