<?xml version="1.0" encoding="UTF-8"?>
 <!--
 All content copyright Terracotta, Inc., unless otherwise indicated. All rights reserved.
 --><!--
  This Terracotta configuration file is intended for use with 
  Terracotta for Hibernate.
   
 -->
 <tc:tc-config xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-4.xsd" xmlns:tc="http://www.terracotta.org/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   
   <servers>
     <!-- Shows where the Terracotta server can be found. -->
     <server host="localhost">
       <data>%(user.home)/terracotta/server-data</data>
       <logs>%(user.home)/terracotta/server-logs</logs>
     </server>
   </servers>
   <!-- Shows where to put the generated client logs -->  
   <clients>
     <logs>%(user.home)/terracotta/client-logs</logs>
     
   <!-- Names the Terracotta Integration Modules (TIM) needed for
        Terracotta for Hibernate and the web container.
        
        -->
     <modules>
       <!-- Replace [3.2|3.3] with the Hibernate version you are using. -->
       
       <!-- Replace <my container> with the Terracotta integration module
            for the supported container you are using. -->
       <module name="tim-tomcat-6.0"  />      
       <module name="tim-hibernate-cache-3.2.5"  />
       
     </modules>
   </clients>
 <!-- The following is used if you are clustering web sessions:
   <application>
   <web-applications>
     <web-application>myWebApp</web-application>
   </web-applications>
 <application>
 -->
 </tc:tc-config>

 Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
 
 * Parsing module: tim-hibernate-cache-3.2.5:latest: No module found on server
 * Parsing module: tim-tomcat-6.0:latest: latest version 2.2.0
 Installing tim-tomcat-6.0 2.2.0 and dependencies...
    INSTALLED: tim-tomcat-6.0 2.2.0 - Ok
    INSTALLED: tim-tomcat-5.5 2.2.0 - Ok
    INSTALLED: tim-tomcat-common 2.2.0 - Ok
    INSTALLED: tim-session-common 2.2.0 - Ok
    INSTALLED: tim-session-ui 2.2.0 - Ok
    INSTALLED: terracotta-toolkit-1.0 1.0.0 [org.terracotta.toolkit] - Ok
 

 lib/ehcache-core-2.2.0.jar
 lib/ehcache-terracotta-2.2.0.jar
 lib/slf4j-api-1.5.11.jar
 lib/slf4j-jdk14-1.5.11.jar
 lib/terracotta-toolkit-1.0-1.0.0.jar
 

 <property name="hibernateProperties">
             <props>
                 <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
                 <prop key="hibernate.show_sql">true</prop>
                 <prop key="hibernate.cglib.use_reflection_optimizer">true</prop>
                 <!--prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop-->
                 <prop key="hibernate.cache.use_second_level_cache">true</prop>
                 <prop key="hibernate.cache.provider_class"> net.sf.ehcache.hibernate.SingletonEhCacheProvider</prop>
                 <prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop>
                 <prop key="net.sf.ehcache.configurationResourceName">/WEB-INF/ehcache.xml</prop>
             </props>
         </property>
 

 
 <?xml version="1.0" encoding="UTF-8"?>
 
 <!--
 CacheManager Configuration
 ==========================
 An ehcache.xml corresponds to a single CacheManager.
 
 See instructions below or the ehcache schema (ehcache.xsd) on how to configure.
 
 System property tokens can be specified in this file which are replaced when the configuration
 is loaded. For example multicastGroupPort=${multicastGroupPort} can be replaced with the
 System property either from an environment variable or a system property specified with a
 command line switch such as -DmulticastGroupPort=4446.
 
 The attributes of <ehcache> are:
 * name - an optional name for the CacheManager.  The name is optional and primarily used
 for documentation or to distinguish Terracotta clustered cache state.  With Terracotta
 clustered caches, a combination of CacheManager name and cache name uniquely identify a
 particular cache store in the Terracotta clustered memory.
 * updateCheck - an optional boolean flag specifying whether this CacheManager should check
 for new versions of Ehcache over the Internet.  If not specified, updateCheck="true".
 * monitoring - an optional setting that determines whether the CacheManager should
 automatically register the SampledCacheMBean with the system MBean server.
 Currently, this monitoring is only useful when using Terracotta clustering and using the
 Terracotta Developer Console. With the "autodetect" value, the presence of Terracotta clustering
 will be detected and monitoring, via the Developer Console, will be enabled. Other allowed values
 are "on" and "off". The default is "autodetect". This setting does not perform any function when
 used with JMX monitors.
 * dynamicConfig - an optional setting that can be used to disable dynamic configuration of caches
 associated with this CacheManager.  By default this is set to true - i.e. dynamic configuration
 is enabled.  Dynamically configurable caches can have their TTI, TTL and maximum disk and
 in-memory capacity changed at runtime through the cache's configuration object.
 -->
 <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="ehcache.xsd"
          updateCheck="true" monitoring="autodetect"
          dynamicConfig="true" >
 
     <!--
     DiskStore configuration
     =======================
 
     The diskStore element is optional. To turn off disk store path creation, comment out the diskStore
     element below.
 
     Configure it if you have overflowToDisk or diskPersistent enabled for any cache.
 
     If it is not configured, and a cache is created which requires a disk store, a warning will be
      issued and java.io.tmpdir will automatically be used.
 
     diskStore has only one attribute - "path". It is the path to the directory where
     .data and .index files will be created.
 
     If the path is one of the following Java System Property it is replaced by its value in the
     running VM. For backward compatibility these should be specified without being enclosed in the ${token}
     replacement syntax.
 
     The following properties are translated:
     * user.home - User's home directory
     * user.dir - User's current working directory
     * java.io.tmpdir - Default temp file path
     * ehcache.disk.store.dir - A system property you would normally specify on the command line
       e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir ...
 
     Subdirectories can be specified below the property e.g. java.io.tmpdir/one
 
     -->
     <diskStore path="java.io.tmpdir"/>
 
 
     <!--
     TransactionManagerLookup configuration
     ======================================
     This class is used by ehcache to lookup the JTA TransactionManager use in the application
     using an XA enabled ehcache. If no class is specified then DefaultTransactionManagerLookup
     will find the TransactionManager in the following order
 
      *GenericJNDI (i.e. jboss, where the property jndiName controls the name of the TransactionManager object to look up)
      *Websphere
      *Bitronix
      *Atomikos
 
     You can provide you own lookup class that implements the net.sf.ehcache.transaction.manager.TransactionManagerLookup interface.
     -->
 
     <transactionManagerLookup class="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup" properties="" propertySeparator=":"/>
 
     <!--
     CacheManagerEventListener
     =========================
     Specifies a CacheManagerEventListenerFactory which is notified when Caches are added
     or removed from the CacheManager.
 
     The attributes of CacheManagerEventListenerFactory are:
     * class - a fully qualified factory class name
     * properties - comma separated properties having meaning only to the factory.
 
     Sets the fully qualified class name to be registered as the CacheManager event listener.
 
     The events include:
     * adding a Cache
     * removing a Cache
 
     Callbacks to listener methods are synchronous and unsynchronized. It is the responsibility
     of the implementer to safely handle the potential performance and thread safety issues
     depending on what their listener is doing.
 
     If no class is specified, no listener is created. There is no default.
     -->
 
     <cacheManagerEventListenerFactory class="" properties=""/>
 
     <!--
     TerracottaConfig
     ========================
     (Enable for Terracotta clustered operation)
 
     Note: You need to install and run one or more Terracotta servers to use Terracotta clustering.
     See http://www.terracotta.org/web/display/orgsite/Download.
 
     Specifies a TerracottaConfig which will be used to configure the Terracotta
     runtime for this CacheManager.
 
     Configuration can be specified in two main ways: by reference to a source of
     configuration or by use of an embedded Terracotta configuration file.
 
     To specify a reference to a source (or sources) of configuration, use the url
     attribute.  The url attribute must contain a comma-separated list of:
     * path to Terracotta configuration file (usually named tc-config.xml)
     * URL to Terracotta configuration file
     * <server host>:<port> of running Terracotta Server instance
 
     Simplest example for pointing to a Terracotta server on this machine:
     <terracottaConfig url="localhost:9510"/>
 
     Example using a path to Terracotta configuration file:
     <terracottaConfig url="/app/config/tc-config.xml"/>
 
     Example using a URL to a Terracotta configuration file:
     <terracottaConfig url="http://internal/ehcache/app/tc-config.xml"/>
 
     Example using multiple Terracotta server instance URLs (for fault tolerance):
     <terracottaConfig url="host1:9510,host2:9510,host3:9510"/>
 
     To embed a Terracotta configuration file within the ehcache configuration, simply
     place a normal Terracotta XML config within the <terracottaConfig> element.
 
     Example:
     <terracottaConfig>
         <tc-config>
             <servers>
                 <server host="server1" name="s1"/>
                 <server host="server2" name="s2"/>
             </servers>
             <clients>
                 <logs>app/logs-%i</logs>
             </clients>
         </tc-config>
     </terracottaConfig>
 
     For more information on the Terracotta configuration, see the Terracotta documentation.
     -->
     <terracottaConfig url="localhost:9510"/>
 
     <!--
     Cache configuration
     ===================
 
     The following attributes are required.
 
     name:
     Sets the name of the cache. This is used to identify the cache. It must be unique.
 
     maxElementsInMemory:
     Sets the maximum number of objects that will be created in memory
 
     maxElementsOnDisk:
     Sets the maximum number of objects that will be maintained in the DiskStore
     The default value is zero, meaning unlimited.
 
     eternal:
     Sets whether elements are eternal. If eternal,  timeouts are ignored and the
     element is never expired.
 
     overflowToDisk:
     Sets whether elements can overflow to disk when the memory store
     has reached the maxInMemory limit.
 
     The following attributes and elements are optional.
 
     timeToIdleSeconds:
     Sets the time to idle for an element before it expires.
     i.e. The maximum amount of time between accesses before an element expires
     Is only used if the element is not eternal.
     Optional attribute. A value of 0 means that an Element can idle for infinity.
     The default value is 0.
 
     timeToLiveSeconds:
     Sets the time to live for an element before it expires.
     i.e. The maximum time between creation time and when an element expires.
     Is only used if the element is not eternal.
     Optional attribute. A value of 0 means that and Element can live for infinity.
     The default value is 0.
 
     diskPersistent:
     Whether the disk store persists between restarts of the Virtual Machine.
     The default value is false.
 
     diskExpiryThreadIntervalSeconds:
     The number of seconds between runs of the disk expiry thread. The default value
     is 120 seconds.
 
     diskSpoolBufferSizeMB:
     This is the size to allocate the DiskStore for a spool buffer. Writes are made
     to this area and then asynchronously written to disk. The default size is 30MB.
     Each spool buffer is used only by its cache. If you get OutOfMemory errors consider
     lowering this value. To improve DiskStore performance consider increasing it. Trace level
     logging in the DiskStore will show if put back ups are occurring.
 
     clearOnFlush:
     whether the MemoryStore should be cleared when flush() is called on the cache.
     By default, this is true i.e. the MemoryStore is cleared.
 
     memoryStoreEvictionPolicy:
     Policy would be enforced upon reaching the maxElementsInMemory limit. Default
     policy is Least Recently Used (specified as LRU). Other policies available -
     First In First Out (specified as FIFO) and Less Frequently Used
     (specified as LFU)
 
     Cache elements can also contain sub elements which take the same format of a factory class
     and properties. Defined sub-elements are:
 
     * cacheEventListenerFactory - Enables registration of listeners for cache events, such as
       put, remove, update, and expire.
 
     * bootstrapCacheLoaderFactory - Specifies a BootstrapCacheLoader, which is called by a
       cache on initialisation to prepopulate itself.
 
     * cacheExtensionFactory - Specifies a CacheExtension, a generic mechansim to tie a class
       which holds a reference to a cache to the cache lifecycle.
 
     * cacheExceptionHandlerFactory - Specifies a CacheExceptionHandler, which is called when
       cache exceptions occur.
 
     * cacheLoaderFactory - Specifies a CacheLoader, which can be used both asynchronously and
       synchronously to load objects into a cache. More than one cacheLoaderFactory element
       can be added, in which case the loaders form a chain which are executed in order. If a
       loader returns null, the next in chain is called.
 
     Cache Event Listeners
 
     All cacheEventListenerFactory elements can take an optional property listenFor that describes
     which events will be delivered in a clustered environment.  The listenFor attribute has the
     following allowed values:
 
     * all - the default is to deliver all local and remote events
     * local - deliver only events originating in the current node
     * remote - deliver only events originating in other nodes
 
     Example of setting up a logging listener for local cache events:
 
     <cacheEventListenerFactory class="my.company.log.CacheLogger"
         listenFor="local" />
 
 
     Cache Exception Handling
     ++++++++++++++++++++++++
 
     By default, most cache operations will propagate a runtime CacheException on failure. An
     interceptor, using a dynamic proxy, may be configured so that a CacheExceptionHandler can
     be configured to intercept Exceptions. Errors are not intercepted.
 
     It is configured as per the following example:
 
       <cacheExceptionHandlerFactory class="com.example.ExampleExceptionHandlerFactory"
                                       properties="logLevel=FINE"/>
 
     Caches with ExceptionHandling configured are not of type Cache, but are of type Ehcache only,
     and are not available using CacheManager.getCache(), but using CacheManager.getEhcache().
 
 
     Cache Loader
     ++++++++++++
 
     A default CacheLoader may be set which loads objects into the cache through asynchronous and
     synchronous methods on Cache. This is different to the bootstrap cache loader, which is used
     only in distributed caching.
 
     It is configured as per the following example:
 
         <cacheLoaderFactory class="com.example.ExampleCacheLoaderFactory"
                                       properties="type=int,startCounter=10"/>
 
     XA Cache
     ++++++++
 
     To enable an ehcache as a participant in the JTA Transaction, just have the following attribute
 
     transactionalMode="xa", otherwise the default is transactionalMode="off"
 
     Cache Writer
     ++++++++++++
 
     A CacheWriter maybe be set to write to an underlying resource. Only one CacheWriter can be
     been to a cache.
 
     It is configured as per the following example for write-through:
 
         <cacheWriter writeMode="write-through" notifyListenersOnException="true">
             <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
                                 properties="type=int,startCounter=10"/>
         </cacheWriter>
 
     And it is configured as per the following example for write-behind:
 
         <cacheWriter writeMode="write-behind" minWriteDelay="1" maxWriteDelay="5"
                      rateLimitPerSecond="5" writeCoalescing="true" writeBatching="true" writeBatchSize="1"
                      retryAttempts="2" retryAttemptDelaySeconds="1">
             <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
                                 properties="type=int,startCounter=10"/>
         </cacheWriter>
 
     The cacheWriter element has the following attributes:
     * writeMode: the write mode, write-through or write-behind
 
     These attributes only apply to write-through mode:
     * notifyListenersOnException: Sets whether to notify listeners when an exception occurs on a writer operation.
 
     These attributes only apply to write-behind mode:
     * minWriteDelay: Set the minimum number of seconds to wait before writing behind. If set to a value greater than 0,
       it permits operations to build up in the queue. This is different from the maximum write delay in that by waiting
       a minimum amount of time, work is always being built up. If the minimum write delay is set to zero and the
       CacheWriter performs its work very quickly, the overhead of processing the write behind queue items becomes very
       noticeable in a cluster since all the operations might be done for individual items instead of for a collection
       of them.
     * maxWriteDelay: Set the maximum number of seconds to wait before writing behind. If set to a value greater than 0,
       it permits operations to build up in the queue to enable effective coalescing and batching optimisations.
     * writeBatching: Sets whether to batch write operations. If set to true, writeAll and deleteAll will be called on
       the CacheWriter rather than write and delete being called for each key. Resources such as databases can perform
       more efficiently if updates are batched, thus reducing load.
     * writeBatchSize: Sets the number of operations to include in each batch when writeBatching is enabled. If there are
       less entries in the write-behind queue than the batch size, the queue length size is used.
     * rateLimitPerSecond: Sets the maximum number of write operations to allow per second when writeBatching is enabled.
     * writeCoalescing: Sets whether to use write coalescing. If set to true and multiple operations on the same key are
       present in the write-behind queue, only the latest write is done, as the others are redundant.
     * retryAttempts: Sets the number of times the operation is retried in the CacheWriter, this happens after the
       original operation.
     * retryAttemptDelaySeconds: Sets the number of seconds to wait before retrying an failed operation.
 
     Cache Extension
     +++++++++++++++
 
     CacheExtensions are a general purpose mechanism to allow generic extensions to a Cache.
     CacheExtensions are tied into the Cache lifecycle.
 
     CacheExtensions are created using the CacheExtensionFactory which has a
     <code>createCacheCacheExtension()</code> method which takes as a parameter a
     Cache and properties. It can thus call back into any public method on Cache, including, of
     course, the load methods.
 
     Extensions are added as per the following example:
 
          <cacheExtensionFactory class="com.example.FileWatchingCacheRefresherExtensionFactory"
                              properties="refreshIntervalMillis=18000, loaderTimeout=3000,
                                          flushPeriod=whatever, someOtherProperty=someValue ..."/>
 
     Terracotta Clustering
     +++++++++++++++++++++
 
     Cache elements can also contain information about whether the cache can be clustered with Terracotta.
     The <terracotta> sub-element has the following attributes:
 
     * clustered=true|false - indicates whether this cache should be clustered with Terracotta. By
       default, if the <terracotta> element is included, clustered=true.
     * valueMode=serialization|identity - indicates whether this cache should be clustered with
       serialized copies of the values or using Terracotta identity mode.  By default, values will
       be cached in serialization mode which is similar to other replicated Ehcache modes.  The identity
       mode is only available in certain Terracotta deployment scenarios and will maintain actual object
       identity of the keys and values across the cluster.  In this case, all users of a value retrieved from
       the cache are using the same clustered value and must provide appropriate locking for any changes
       made to the value (or objects referred to by the value).
     * synchronousWrites=true|false - When set to true, clustered caches use
       Terracotta SYNCHRONOUS WRITE locks. Asynchronous writes (synchronousWrites="false") maximize performance by
       allowing clients to proceed without waiting for a "transaction received" acknowledgement from the server.
       Synchronous writes (synchronousWrites="true") maximize data safety by requiring that a client receive server
       acknowledgement of a transaction before that client can proceed. If coherence mode is disabled using
       configuration (coherent="false") or through the coherence API, only asynchronous writes can occur
       (synchronousWrites="true" is ignored). By default this value is false (i.e. clustered caches use normal
       Terracotta WRITE locks).
     * coherent=true|false - indicates whether this cache should have coherent reads and writes with guaranteed
       consistency across the cluster.  By default, its value is true.  If this attribute is set to false
       (or "incoherent" mode), values from the cache are read without locking, possibly yielding stale data.
       Writes to a cache in incoherent mode are batched and applied without acquiring cluster-wide locks,
       possibly creating inconsistent values across cluster. Incoherent mode is a performance optimization
       with weaker concurrency guarantees and should generally be used for bulk-loading caches, for loading
       a read-only cache, or where the application that can tolerate reading stale data. This setting overrides
       coherentReads, which is deprecated.
     * copyOnRead=true|false - indicates whether cache values are deserialized on every read or if the
       materialized cache value can be re-used between get() calls. This setting is useful if a cache
       is being shared by callers with disparate classloaders or to prevent local drift if keys/values
       are mutated locally w/o putting back to the cache. NOTE: This setting is only relevant for caches
       with valueMode=serialization
 
     Simplest example to indicate clustering:
         <terracotta/>
 
     To indicate the cache should not be clustered (or remove the <terracotta> element altogether):
         <terracotta clustered="false"/>
 
     To indicate the cache should be clustered using identity mode:
         <terracotta clustered="true" valueMode="identity"/>
 
     To indicate the cache should be clustered using incoherent mode for bulk load:
         <terracotta clustered="true" coherent="false"/>
 
     To indicate the cache should be clustered using synchronous-write locking level:
         <terracotta clustered="true" synchronousWrites="true"/>
     -->
 
     <!--
     Mandatory Default Cache configuration. These settings will be applied to caches
     created programmtically using CacheManager.add(String cacheName).
 
     The defaultCache has an implicit name "default" which is a reserved cache name.
     -->
     <defaultCache
            maxElementsInMemory="0"
            eternal="false"
            overflowToDisk="true"
            timeToIdleSeconds="1200"
            timeToLiveSeconds="1200">
       <terracotta/>
     </defaultCache>
 
     <!--
     Sample caches. Following are some example caches. Remove these before use.
     -->
 
     <!--
     Sample cache named sampleCache1
     This cache contains a maximum in memory of 10000 elements, and will expire
     an element if it is idle for more than 5 minutes and lives for more than
     10 minutes.
 
     If there are more than 10000 elements it will overflow to the
     disk cache, which in this configuration will go to wherever java.io.tmp is
     defined on your system. On a standard Linux system this will be /tmp"
     -->
     <cache name="sampleCache1"
            maxElementsInMemory="10000"
            maxElementsOnDisk="1000"
            eternal="false"
            overflowToDisk="true"
            diskSpoolBufferSizeMB="20"
            timeToIdleSeconds="300"
            timeToLiveSeconds="600"
            memoryStoreEvictionPolicy="LFU"
             />
 
 
     <!--
     Sample cache named sampleCache2
     This cache has a maximum of 1000 elements in memory. There is no overflow to disk, so 1000
     is also the maximum cache size. Note that when a cache is eternal, timeToLive and
     timeToIdle are not used and do not need to be specified.
     -->
     <cache name="sampleCache2"
            maxElementsInMemory="1000"
            eternal="true"
            overflowToDisk="false"
            memoryStoreEvictionPolicy="FIFO"
             />
 
 
     <!--
     Sample cache named sampleCache3. This cache overflows to disk. The disk store is
     persistent between cache and VM restarts. The disk expiry thread interval is set to 10
     minutes, overriding the default of 2 minutes.
     -->
     <cache name="sampleCache3"
            maxElementsInMemory="500"
            eternal="false"
            overflowToDisk="true"
            timeToIdleSeconds="300"
            timeToLiveSeconds="600"
            diskPersistent="true"
            diskExpiryThreadIntervalSeconds="1"
            memoryStoreEvictionPolicy="LFU"
             />
 
     <!--
     Sample Terracotta clustered cache named sampleTerracottaCache.
     This cache uses Terracotta to cluster the contents of the cache.
     -->
     <cache name="sampleTerracottaCache"
            maxElementsInMemory="1000"
            eternal="false"
            timeToIdleSeconds="3600"
            timeToLiveSeconds="1800"
            overflowToDisk="false">
 
         <terracotta/>
     </cache>
 
       <!--
       Sample xa enabled cache name xaCache
     -->
 
     <cache name="xaCache"
         maxElementsInMemory="500"
         eternal="false"
         timeToIdleSeconds="300"
         timeToLiveSeconds="600"
         overflowToDisk="false"
         diskPersistent="false"
         diskExpiryThreadIntervalSeconds="1"
         transactionalMode="xa">
       <terracotta clustered="true"/>
   </cache>
 
 </ehcache>
 

 
 plop@plop-laptop:~/terracotta/terracotta-3.3.0/bin$ ./start-tc-server.sh 
 2010-08-10 20:48:30,538 INFO - Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
 2010-08-10 20:48:31,558 INFO - Successfully loaded base configuration from Java resource at '/com/tc/config/schema/setup/default-config.xml', relative to class com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.
 2010-08-10 20:48:31,967 INFO - Log file: '/home/plop/terracotta/server-logs/terracotta-server.log'.
 2010-08-10 20:48:34,791 INFO - Available Max Runtime Memory: 496MB
 2010-08-10 20:48:37,579 INFO - JMX Server started. Available at URL[service:jmx:jmxmp://0.0.0.0:9520]
 2010-08-10 20:48:44,045 INFO - Becoming State[ ACTIVE-COORDINATOR ]
 2010-08-10 20:48:44,101 INFO - Terracotta Server instance has started up as ACTIVE node on 0:0:0:0:0:0:0:0:9510 successfully, and is now ready for work.
 

 
 <?xml version="1.0" encoding="UTF-8"?>
 
 <!--
 CacheManager Configuration
 ==========================
 An ehcache.xml corresponds to a single CacheManager.
 
 See instructions below or the ehcache schema (ehcache.xsd) on how to configure.
 
 System property tokens can be specified in this file which are replaced when the configuration
 is loaded. For example multicastGroupPort=${multicastGroupPort} can be replaced with the
 System property either from an environment variable or a system property specified with a
 command line switch such as -DmulticastGroupPort=4446.
 
 The attributes of <ehcache> are:
 * name - an optional name for the CacheManager.  The name is optional and primarily used
 for documentation or to distinguish Terracotta clustered cache state.  With Terracotta
 clustered caches, a combination of CacheManager name and cache name uniquely identify a
 particular cache store in the Terracotta clustered memory.
 * updateCheck - an optional boolean flag specifying whether this CacheManager should check
 for new versions of Ehcache over the Internet.  If not specified, updateCheck="true".
 * monitoring - an optional setting that determines whether the CacheManager should
 automatically register the SampledCacheMBean with the system MBean server.
 Currently, this monitoring is only useful when using Terracotta clustering and using the
 Terracotta Developer Console. With the "autodetect" value, the presence of Terracotta clustering
 will be detected and monitoring, via the Developer Console, will be enabled. Other allowed values
 are "on" and "off". The default is "autodetect". This setting does not perform any function when
 used with JMX monitors.
 * dynamicConfig - an optional setting that can be used to disable dynamic configuration of caches
 associated with this CacheManager.  By default this is set to true - i.e. dynamic configuration
 is enabled.  Dynamically configurable caches can have their TTI, TTL and maximum disk and
 in-memory capacity changed at runtime through the cache's configuration object.
 -->
 <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="ehcache.xsd"
          updateCheck="true" monitoring="autodetect"
          dynamicConfig="true" >
 
     <!--
     DiskStore configuration
     =======================
 
     The diskStore element is optional. To turn off disk store path creation, comment out the diskStore
     element below.
 
     Configure it if you have overflowToDisk or diskPersistent enabled for any cache.
 
     If it is not configured, and a cache is created which requires a disk store, a warning will be
      issued and java.io.tmpdir will automatically be used.
 
     diskStore has only one attribute - "path". It is the path to the directory where
     .data and .index files will be created.
 
     If the path is one of the following Java System Property it is replaced by its value in the
     running VM. For backward compatibility these should be specified without being enclosed in the ${token}
     replacement syntax.
 
     The following properties are translated:
     * user.home - User's home directory
     * user.dir - User's current working directory
     * java.io.tmpdir - Default temp file path
     * ehcache.disk.store.dir - A system property you would normally specify on the command line
       e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir ...
 
     Subdirectories can be specified below the property e.g. java.io.tmpdir/one
 
     -->
     <diskStore path="java.io.tmpdir"/>
 
 
     <!--
     TransactionManagerLookup configuration
     ======================================
     This class is used by ehcache to lookup the JTA TransactionManager use in the application
     using an XA enabled ehcache. If no class is specified then DefaultTransactionManagerLookup
     will find the TransactionManager in the following order
 
      *GenericJNDI (i.e. jboss, where the property jndiName controls the name of the TransactionManager object to look up)
      *Websphere
      *Bitronix
      *Atomikos
 
     You can provide you own lookup class that implements the net.sf.ehcache.transaction.manager.TransactionManagerLookup interface.
     -->
 
     <transactionManagerLookup class="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup" properties="" propertySeparator=":"/>
 
     <!--
     CacheManagerEventListener
     =========================
     Specifies a CacheManagerEventListenerFactory which is notified when Caches are added
     or removed from the CacheManager.
 
     The attributes of CacheManagerEventListenerFactory are:
     * class - a fully qualified factory class name
     * properties - comma separated properties having meaning only to the factory.
 
     Sets the fully qualified class name to be registered as the CacheManager event listener.
 
     The events include:
     * adding a Cache
     * removing a Cache
 
     Callbacks to listener methods are synchronous and unsynchronized. It is the responsibility
     of the implementer to safely handle the potential performance and thread safety issues
     depending on what their listener is doing.
 
     If no class is specified, no listener is created. There is no default.
     -->
 
     <cacheManagerEventListenerFactory class="" properties=""/>
 
     <!--
     TerracottaConfig
     ========================
     (Enable for Terracotta clustered operation)
 
     Note: You need to install and run one or more Terracotta servers to use Terracotta clustering.
     See http://www.terracotta.org/web/display/orgsite/Download.
 
     Specifies a TerracottaConfig which will be used to configure the Terracotta
     runtime for this CacheManager.
 
     Configuration can be specified in two main ways: by reference to a source of
     configuration or by use of an embedded Terracotta configuration file.
 
     To specify a reference to a source (or sources) of configuration, use the url
     attribute.  The url attribute must contain a comma-separated list of:
     * path to Terracotta configuration file (usually named tc-config.xml)
     * URL to Terracotta configuration file
     * <server host>:<port> of running Terracotta Server instance
 
     Simplest example for pointing to a Terracotta server on this machine:
     <terracottaConfig url="localhost:9510"/>
 
     Example using a path to Terracotta configuration file:
     <terracottaConfig url="/app/config/tc-config.xml"/>
 
     Example using a URL to a Terracotta configuration file:
     <terracottaConfig url="http://internal/ehcache/app/tc-config.xml"/>
 
     Example using multiple Terracotta server instance URLs (for fault tolerance):
     <terracottaConfig url="host1:9510,host2:9510,host3:9510"/>
 
     To embed a Terracotta configuration file within the ehcache configuration, simply
     place a normal Terracotta XML config within the <terracottaConfig> element.
 
     Example:
     <terracottaConfig>
         <tc-config>
             <servers>
                 <server host="server1" name="s1"/>
                 <server host="server2" name="s2"/>
             </servers>
             <clients>
                 <logs>app/logs-%i</logs>
             </clients>
         </tc-config>
     </terracottaConfig>
 
     For more information on the Terracotta configuration, see the Terracotta documentation.
     -->
     <terracottaConfig url="localhost:9510"/>
 
     <!--
     Cache configuration
     ===================
 
     The following attributes are required.
 
     name:
     Sets the name of the cache. This is used to identify the cache. It must be unique.
 
     maxElementsInMemory:
     Sets the maximum number of objects that will be created in memory
 
     maxElementsOnDisk:
     Sets the maximum number of objects that will be maintained in the DiskStore
     The default value is zero, meaning unlimited.
 
     eternal:
     Sets whether elements are eternal. If eternal,  timeouts are ignored and the
     element is never expired.
 
     overflowToDisk:
     Sets whether elements can overflow to disk when the memory store
     has reached the maxInMemory limit.
 
     The following attributes and elements are optional.
 
     timeToIdleSeconds:
     Sets the time to idle for an element before it expires.
     i.e. The maximum amount of time between accesses before an element expires
     Is only used if the element is not eternal.
     Optional attribute. A value of 0 means that an Element can idle for infinity.
     The default value is 0.
 
     timeToLiveSeconds:
     Sets the time to live for an element before it expires.
     i.e. The maximum time between creation time and when an element expires.
     Is only used if the element is not eternal.
     Optional attribute. A value of 0 means that and Element can live for infinity.
     The default value is 0.
 
     diskPersistent:
     Whether the disk store persists between restarts of the Virtual Machine.
     The default value is false.
 
     diskExpiryThreadIntervalSeconds:
     The number of seconds between runs of the disk expiry thread. The default value
     is 120 seconds.
 
     diskSpoolBufferSizeMB:
     This is the size to allocate the DiskStore for a spool buffer. Writes are made
     to this area and then asynchronously written to disk. The default size is 30MB.
     Each spool buffer is used only by its cache. If you get OutOfMemory errors consider
     lowering this value. To improve DiskStore performance consider increasing it. Trace level
     logging in the DiskStore will show if put back ups are occurring.
 
     clearOnFlush:
     whether the MemoryStore should be cleared when flush() is called on the cache.
     By default, this is true i.e. the MemoryStore is cleared.
 
     memoryStoreEvictionPolicy:
     Policy would be enforced upon reaching the maxElementsInMemory limit. Default
     policy is Least Recently Used (specified as LRU). Other policies available -
     First In First Out (specified as FIFO) and Less Frequently Used
     (specified as LFU)
 
     Cache elements can also contain sub elements which take the same format of a factory class
     and properties. Defined sub-elements are:
 
     * cacheEventListenerFactory - Enables registration of listeners for cache events, such as
       put, remove, update, and expire.
 
     * bootstrapCacheLoaderFactory - Specifies a BootstrapCacheLoader, which is called by a
       cache on initialisation to prepopulate itself.
 
     * cacheExtensionFactory - Specifies a CacheExtension, a generic mechansim to tie a class
       which holds a reference to a cache to the cache lifecycle.
 
     * cacheExceptionHandlerFactory - Specifies a CacheExceptionHandler, which is called when
       cache exceptions occur.
 
     * cacheLoaderFactory - Specifies a CacheLoader, which can be used both asynchronously and
       synchronously to load objects into a cache. More than one cacheLoaderFactory element
       can be added, in which case the loaders form a chain which are executed in order. If a
       loader returns null, the next in chain is called.
 
     Cache Event Listeners
 
     All cacheEventListenerFactory elements can take an optional property listenFor that describes
     which events will be delivered in a clustered environment.  The listenFor attribute has the
     following allowed values:
 
     * all - the default is to deliver all local and remote events
     * local - deliver only events originating in the current node
     * remote - deliver only events originating in other nodes
 
     Example of setting up a logging listener for local cache events:
 
     <cacheEventListenerFactory class="my.company.log.CacheLogger"
         listenFor="local" />
 
 
     Cache Exception Handling
     ++++++++++++++++++++++++
 
     By default, most cache operations will propagate a runtime CacheException on failure. An
     interceptor, using a dynamic proxy, may be configured so that a CacheExceptionHandler can
     be configured to intercept Exceptions. Errors are not intercepted.
 
     It is configured as per the following example:
 
       <cacheExceptionHandlerFactory class="com.example.ExampleExceptionHandlerFactory"
                                       properties="logLevel=FINE"/>
 
     Caches with ExceptionHandling configured are not of type Cache, but are of type Ehcache only,
     and are not available using CacheManager.getCache(), but using CacheManager.getEhcache().
 
 
     Cache Loader
     ++++++++++++
 
     A default CacheLoader may be set which loads objects into the cache through asynchronous and
     synchronous methods on Cache. This is different to the bootstrap cache loader, which is used
     only in distributed caching.
 
     It is configured as per the following example:
 
         <cacheLoaderFactory class="com.example.ExampleCacheLoaderFactory"
                                       properties="type=int,startCounter=10"/>
 
     XA Cache
     ++++++++
 
     To enable an ehcache as a participant in the JTA Transaction, just have the following attribute
 
     transactionalMode="xa", otherwise the default is transactionalMode="off"
 
     Cache Writer
     ++++++++++++
 
     A CacheWriter maybe be set to write to an underlying resource. Only one CacheWriter can be
     been to a cache.
 
     It is configured as per the following example for write-through:
 
         <cacheWriter writeMode="write-through" notifyListenersOnException="true">
             <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
                                 properties="type=int,startCounter=10"/>
         </cacheWriter>
 
     And it is configured as per the following example for write-behind:
 
         <cacheWriter writeMode="write-behind" minWriteDelay="1" maxWriteDelay="5"
                      rateLimitPerSecond="5" writeCoalescing="true" writeBatching="true" writeBatchSize="1"
                      retryAttempts="2" retryAttemptDelaySeconds="1">
             <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
                                 properties="type=int,startCounter=10"/>
         </cacheWriter>
 
     The cacheWriter element has the following attributes:
     * writeMode: the write mode, write-through or write-behind
 
     These attributes only apply to write-through mode:
     * notifyListenersOnException: Sets whether to notify listeners when an exception occurs on a writer operation.
 
     These attributes only apply to write-behind mode:
     * minWriteDelay: Set the minimum number of seconds to wait before writing behind. If set to a value greater than 0,
       it permits operations to build up in the queue. This is different from the maximum write delay in that by waiting
       a minimum amount of time, work is always being built up. If the minimum write delay is set to zero and the
       CacheWriter performs its work very quickly, the overhead of processing the write behind queue items becomes very
       noticeable in a cluster since all the operations might be done for individual items instead of for a collection
       of them.
     * maxWriteDelay: Set the maximum number of seconds to wait before writing behind. If set to a value greater than 0,
       it permits operations to build up in the queue to enable effective coalescing and batching optimisations.
     * writeBatching: Sets whether to batch write operations. If set to true, writeAll and deleteAll will be called on
       the CacheWriter rather than write and delete being called for each key. Resources such as databases can perform
       more efficiently if updates are batched, thus reducing load.
     * writeBatchSize: Sets the number of operations to include in each batch when writeBatching is enabled. If there are
       less entries in the write-behind queue than the batch size, the queue length size is used.
     * rateLimitPerSecond: Sets the maximum number of write operations to allow per second when writeBatching is enabled.
     * writeCoalescing: Sets whether to use write coalescing. If set to true and multiple operations on the same key are
       present in the write-behind queue, only the latest write is done, as the others are redundant.
     * retryAttempts: Sets the number of times the operation is retried in the CacheWriter, this happens after the
       original operation.
     * retryAttemptDelaySeconds: Sets the number of seconds to wait before retrying an failed operation.
 
     Cache Extension
     +++++++++++++++
 
     CacheExtensions are a general purpose mechanism to allow generic extensions to a Cache.
     CacheExtensions are tied into the Cache lifecycle.
 
     CacheExtensions are created using the CacheExtensionFactory which has a
     <code>createCacheCacheExtension()</code> method which takes as a parameter a
     Cache and properties. It can thus call back into any public method on Cache, including, of
     course, the load methods.
 
     Extensions are added as per the following example:
 
          <cacheExtensionFactory class="com.example.FileWatchingCacheRefresherExtensionFactory"
                              properties="refreshIntervalMillis=18000, loaderTimeout=3000,
                                          flushPeriod=whatever, someOtherProperty=someValue ..."/>
 
     Terracotta Clustering
     +++++++++++++++++++++
 
     Cache elements can also contain information about whether the cache can be clustered with Terracotta.
     The <terracotta> sub-element has the following attributes:
 
     * clustered=true|false - indicates whether this cache should be clustered with Terracotta. By
       default, if the <terracotta> element is included, clustered=true.
     * valueMode=serialization|identity - indicates whether this cache should be clustered with
       serialized copies of the values or using Terracotta identity mode.  By default, values will
       be cached in serialization mode which is similar to other replicated Ehcache modes.  The identity
       mode is only available in certain Terracotta deployment scenarios and will maintain actual object
       identity of the keys and values across the cluster.  In this case, all users of a value retrieved from
       the cache are using the same clustered value and must provide appropriate locking for any changes
       made to the value (or objects referred to by the value).
     * synchronousWrites=true|false - When set to true, clustered caches use
       Terracotta SYNCHRONOUS WRITE locks. Asynchronous writes (synchronousWrites="false") maximize performance by
       allowing clients to proceed without waiting for a "transaction received" acknowledgement from the server.
       Synchronous writes (synchronousWrites="true") maximize data safety by requiring that a client receive server
       acknowledgement of a transaction before that client can proceed. If coherence mode is disabled using
       configuration (coherent="false") or through the coherence API, only asynchronous writes can occur
       (synchronousWrites="true" is ignored). By default this value is false (i.e. clustered caches use normal
       Terracotta WRITE locks).
     * coherent=true|false - indicates whether this cache should have coherent reads and writes with guaranteed
       consistency across the cluster.  By default, its value is true.  If this attribute is set to false
       (or "incoherent" mode), values from the cache are read without locking, possibly yielding stale data.
       Writes to a cache in incoherent mode are batched and applied without acquiring cluster-wide locks,
       possibly creating inconsistent values across cluster. Incoherent mode is a performance optimization
       with weaker concurrency guarantees and should generally be used for bulk-loading caches, for loading
       a read-only cache, or where the application that can tolerate reading stale data. This setting overrides
       coherentReads, which is deprecated.
     * copyOnRead=true|false - indicates whether cache values are deserialized on every read or if the
       materialized cache value can be re-used between get() calls. This setting is useful if a cache
       is being shared by callers with disparate classloaders or to prevent local drift if keys/values
       are mutated locally w/o putting back to the cache. NOTE: This setting is only relevant for caches
       with valueMode=serialization
 
     Simplest example to indicate clustering:
         <terracotta/>
 
     To indicate the cache should not be clustered (or remove the <terracotta> element altogether):
         <terracotta clustered="false"/>
 
     To indicate the cache should be clustered using identity mode:
         <terracotta clustered="true" valueMode="identity"/>
 
     To indicate the cache should be clustered using incoherent mode for bulk load:
         <terracotta clustered="true" coherent="false"/>
 
     To indicate the cache should be clustered using synchronous-write locking level:
         <terracotta clustered="true" synchronousWrites="true"/>
     -->
 
     <!--
     Mandatory Default Cache configuration. These settings will be applied to caches
     created programmtically using CacheManager.add(String cacheName).
 
     The defaultCache has an implicit name "default" which is a reserved cache name.
     -->
     <defaultCache
           maxElementsInMemory="1000"
            eternal="true"
            overflowToDisk="false"
            memoryStoreEvictionPolicy="LFU"
            statistics="true"/>        
     <cacheManagerPeerListenerFactory class="org.terracotta.ehcachedx.monitor.probe.ProbePeerListenerFactory"
 properties="serverAddress=localhost, serverPort=9510" />
 </ehcache>
 

 lib/ehcache-core-2.2.0.jar
 lib/ehcache-terracotta-2.2.0.jar
 lib/slf4j-api-1.5.11.jar
 lib/slf4j-jdk14-1.5.11.jar
 lib/terracotta-toolkit-1.0-1.0.0.jar
 lib/ehcache-probe-1.0.1.jar
 

  <property name="hibernateProperties">
             <props>
                 <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
                 <prop key="hibernate.show_sql">true</prop>
                 <prop key="hibernate.cglib.use_reflection_optimizer">true</prop>                
                 <prop key="hibernate.cache.use_second_level_cache">true</prop>
                 <prop key="hibernate.cache.provider_class"> net.sf.ehcache.hibernate.SingletonEhCacheProvider</prop>
                 <prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop>
                 <prop key="net.sf.ehcache.configurationResourceName">/WEB-INF/ehcache.xml</prop>
                 <prop key="hibernate.generate_statistics">true</prop>
             </props>
         </property>
 

darknight@darknight-laptop:~/terracotta/terracotta-3.3.0-ee/bin$ ./start-tc-server.sh 
 2010-08-12 10:05:53,282 INFO - Terracotta Enterprise 3.3.0, as of 20100716-160738 (Revision 7871-15922 by cruise@su10mo5 from 3.3)
 2010-08-12 10:05:54,089 INFO - Successfully loaded base configuration from Java resource at '/com/tc/config/schema/setup/default-config.xml', relative to class com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.
 2010-08-12 10:05:54,454 INFO - Log file: '/home/darknight/terracotta/server-logs/terracotta-server.log'.
 2010-08-12 10:05:54,469 INFO - Product key found at: /home/darknight/terracotta/terracotta-3.3.0-ee/product.key
 2010-08-12 10:05:54,679 INFO - 
 ---------------- Terracotta product key --------------
 License type = Trial
 License number = THIS IS A TRIAL LICENSE KEY FOR TERRACOTTA ENTERPRISE SUITE FX
 Licensee = DOWNLOAD_AGREEMENT_TRIAL_AGREED
 Product = Enterprise Suite
 Edition = FX
 Max clients = 10
 Capabilities = Terracotta operator console, DCV2, sessions, roots, authentication, ehcache, quartz, server striping
 Expiration date = 2010-10-17
 ------------------------------------------------------
 2010-08-12 10:05:57,460 INFO - Available Max Runtime Memory: 496MB
 2010-08-12 10:06:00,288 INFO - JMX Server started. Available at URL[service:jmx:jmxmp://0.0.0.0:9520]
 2010-08-12 10:06:06,560 INFO - Becoming State[ ACTIVE-COORDINATOR ]
 2010-08-12 10:06:06,612 INFO - Terracotta Server instance has started up as ACTIVE node on 0:0:0:0:0:0:0:0:9510 successfully, and is now ready for work.