[jboss-user] [JBossCache] - binding of DummyTransactionManager failed javax.naming.Namin

[jiafan1]

I am JBoss TreeCache in Spring. When I run unit tests. Everything seems fine. But when I deploy the war file to tomcat, the following exception is thrown:

2006-09-27 15:33:00,321 ERROR [main] org.jboss.cache.transaction.DummyTransactionManager.getInstance (DummyTransactionManager.java:37) binding of DummyTransactionManager failed
javax.naming.NamingException: Context is read only
        at org.apache.naming.NamingContext.checkWritable(NamingContext.java:902)
        at org.apache.naming.NamingContext.bind(NamingContext.java:830)
        at org.apache.naming.NamingContext.bind(NamingContext.java:170)
        at org.apache.naming.NamingContext.bind(NamingContext.java:186)
        at org.apache.naming.SelectorContext.bind(SelectorContext.java:170)
        at javax.naming.InitialContext.bind(InitialContext.java:359)
        at org.jboss.cache.transaction.DummyTransactionManager.getInstance(DummyTransactionManager.java:33)
        at org.jboss.cache.GenericTransactionManagerLookup.getTransactionManager(GenericTransactionManagerLookup.java:76)
        at org.jboss.cache.TreeCache._createService(TreeCache.java:1314)
        at org.jboss.cache.TreeCache.createService(TreeCache.java:1300)

My jboss cache configuration file is as follows (the cache runs in standalone mode),


	

    
	
		jboss:service=Naming
		<!-- -->
		jboss:service=TransactionManager
		<!---->
		
		<!-- Configure the TransactionManager -->
		
		org.jboss.cache.GenericTransactionManagerLookup
		<!-- -->
		
		<!--
            Node locking scheme:
                OPTIMISTIC
                PESSIMISTIC (default)
        
        OPTIMISTIC
		-->
		
		<!--
		Node locking level : SERIALIZABLE
		REPEATABLE_READ (default)
		READ_COMMITTED
		READ_UNCOMMITTED
		NONE
		-->
		REPEATABLE_READ
		
		<!--
		Valid modes are LOCAL
		REPL_ASYNC
		REPL_SYNC
		INVALIDATION_ASYNC
		INVALIDATION_SYNC
		-->
		REPL_SYNC
		
		<!-- Name of cluster. Needs to be the same for all clusters, in order
		to find each other
		-->
		JTVCORE-Cluster
		
		<!-- JGroups protocol stack properties. Can also be a URL,
		e.g. file:/home/bela/default.xml
		
		-->
		
			
				<UDP mcast_send_buf_size="32000"
					mcast_port="45566"
					ucast_recv_buf_size="64000"
					mcast_addr="228.8.8.8"
					bind_addr="10.1.11.8"
					loopback="false"
					mcast_recv_buf_size="64000"
					max_bundle_size="60000"
					max_bundle_timeout="30"
					use_incoming_packet_handler="false"
					use_outgoing_packet_handler="false"
					ucast_send_buf_size="32000"
					ip_ttl="32"
					enable_bundling="false"/>
				<PING timeout="2000"
					num_initial_members="4"/>
				<MERGE2 max_interval="10000"
					min_interval="5000"/>
				<FD timeout="2000"
					max_tries="3"
					shun="true"/>
				<VERIFY_SUSPECT timeout="1500"/>
				<pbcast.NAKACK max_xmit_size="8192"
					use_mcast_xmit="false"
					gc_lag="50"
					retransmit_timeout="600,1200,2400,4800"/>
				
			
				<!--
				- desired_avg_gossip: periodically sends STABLE messages around. 0 disables this
				- max_bytes: max number of bytes received from anyone until a STABLE message is sent. Use either this or
							 desired_avg_gossip, but not both ! 0 disables it.
				- stability_delay: range (number of milliseconds) that we wait until sending a STABILITY message.
				  This prevents STABILITY multicast storms. If max_bytes is used, this should be set to a low value (> 0 though !).
				-->
				<pbcast.STABLE stability_delay="1000"
					desired_avg_gossip="20000"
					max_bytes="0"/>
				<FRAG frag_size="8192"
					down_thread="false"
					up_thread="false"/>
				<VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
				<pbcast.GMS print_local_addr="true"
					join_timeout="3000"
					join_retry_timeout="2000"
					shun="true"/>
				<pbcast.STATE_TRANSFER 
					down_thread="false" 
					up_thread="false"/>		
			
		
		
        <!--
         Whether or not to fetch state on joining a cluster
         NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive.
        -->
		<!-- -->
		true
		<!-- -->
		
		<!--
		The max amount of time (in milliseconds) we wait until the
		initial state (ie. the contents of the cache) are retrieved from
		existing members in a clustered environment
		-->
		20000
		
		<!--
		Number of milliseconds to wait until all responses for a
		synchronous call have been received.
		-->
		20000
		
		<!-- Max number of milliseconds to wait for a lock acquisition -->
		15000
		
		<!-- Name of the eviction policy class. -->
		<!--attribute name="EvictionPolicyClass"></attribute-->

		<!-- 
		org.jboss.cache.eviction.LRUPolicy
		-->
		
		<!-- Specific eviction policy configurations. This is LRU -->
		
			
				5
				<!-- Cache wide default /com/jtv/core-->
				
					5000
					0
				
				
					2000
					0
				
				
					10000
					0
				
			
		
		
		<!--
		Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped
		class loader, e.g., inside an application server. Default is "false".
		-->
		false
		
		<!-- New 1.3.x cache loader config block -->
       	
           
               <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
               true
               /
               false<!--false-->

               <!-- we can now have multiple cache loaders, which get chained -->
               
                   org.jboss.cache.loader.FileCacheLoader
                   <!-- same as the old CacheLoaderConfig attribute -->
                   
                        location=/tmp
                   
                   <!-- whether the cache loader writes are asynchronous -->
                   false
                   <!-- only one cache loader in the chain may set fetchPersistentState to true.
                       An exception is thrown if more than one cache loader sets this to true. -->
                   true
                   <!-- determines whether this cache loader ignores writes - defaults to false. -->
                   false
               

           
        
	


Any hints about what is wrong?

Thanks in advance.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974690#3974690

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974690