Release Notes for Terracotta 3.2.1

New Features

1. Ehcache as a Hibernate 2nd Level Cache.
Review the Terracotta docs and the Ehcache docs on this topic.
Ehcache 2.0 now integrates support for fully coherent distributed caching as a Hibernate Second-Level Cache, as well as for caches accessed directly through the Ehcache API. One pair of jars covers both. Switching between local and distributed implementations is done with a simple config change. This replaces the previous terracotta-hibernate-cache and terracotta-hibernate-agent jars. No java agent is needed. These new jars also have no specific JDK or container restrictions. Support for the new Hibernate 3.3 SPI has also been added & using this (net.sf.ehcache.hibernate.EhCacheRegionFactory rather than net.sf.ehcache.hibernate.EhCacheProvider) is recommended for Hibernate 3.3.

2. Write-behind in Ehcache.
Review the docs on this topic.

3. JTA support in Ehcache.
Review the docs on this topic.
This is designed to work with any JTA-compliant Transaction manager. Our testing was done with JBossTM, Bitronix and Atomikos.

4. Optimized bulk load in Ehcache.
Review the docs on this topic.

5. Management. Dynamic config for Ehcache - for example TTI and TTL for caches can be changed on the fly via the console or JMX. Check out the updated developer console to see this feature.

6. Express Web Sessions Clustering. Now Web Sessions Clustering is supported in Express mode - i.e. without needing a boot jar or custom annotations. This new approach is designed to work with frameworks that are developed for serialization-based clustering and not to require any Terracotta-specific configuration. We recommend you review the doc section on the topic.
Then try out the demo samples included in the kit by running the start-demo.sh script in the sub-directory of the sessions/samples directory for the sample you choose. This release of Express Web Sessions Clustering includes support for Tomcat, Jetty, JBoss and Weblogic.

7. OSGi Support
Review the docs on this topic.

Summary of Changes in Ehcache 2.0 and Terracotta 3.2.1

Expected Updates and Scheduled Bug Fixes

in the 2.0 EHC Jira Project
in the 3.2.1 CDV Jira Project
in Terracotta Forge Projects

Kit Changes

The Terracotta Kit structure has changed with four top level directories aligning with Terracota Products. Please review the kit structure if you have a previous Terracotta installation, as any custom scripts you have created may no longer work without adjustments.

Additional Improvements

The Terracotta 3.2.1 Kit includes Quartz 1.7.3

Known Open Issues

CDV-1453 interleaving txn not support in EhcacheXAResource when the TM is Atomikos

FORGE-582 With cluster events enabled terracotta clustered cache, adding an element to a cache with tti/ttl 30 secs and checking the element after 60 secs. This triggers evicted event, then expired event.

FORGE-583 Exception while starting the transaction in weblogic10 container. The error message seens is "Attempt to start an XA Transaction inside a Resource Adapter's Local Transaction is illegal"

• Workaround: In this case the parallel completion of the XA transactions must be suppressed.
  (see the XML schema: http://www.bea.com/ns/weblogic/920/domain.xsd)
  In the domain configuration.xml in the <jtaType> element

  need to set following property in weblogic domain config.xml 
  
  <jta> 
      ... 
      <checkpoint-interval-seconds>300</checkpoint-interval-seconds> 
      <parallel-xa-enabled>false</parallel-xa-enabled> 
      ... 
    </jta> 
  
  add the following line to ehcache.xml 
   <transactionManagerLookup 
                  class="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup" 
                  properties="jndiName=javax.transaction.UserTransaction" propertySeparator=";" />

CDV-1455 Delays in return of setting Coherent to true in Developer Console

CDV-1457 Clustered Ehcache write behind isn't properly scoped

EHC-641 Creating cacheMgr programatically not viewable in Developer Console

• Workaround: Update default configuration to include Terracotta Clustered

EHC-644 When a transaction is being prepared, while another one is commiting, that have at least 2 keys in common being accessed in "non-natural order of the locks" you end up with a deadlock.