Page Comparison

Introduction

This page will help a developer understand the basic ideas to Terracotta cluster enabling a Sakai tool. This page rely on the code changes documented in the High Level Design and Jira Task Description pages. The steps and ideas presented here are a guideline and will most likely not cover all situation that will come up when trying to cluster enable a tool.

...

svn export
https://source.sakaiproject.org/svn/msub/unicon.net/content/branches/session-clustering-2-5-x/content-tim
announcement/announcement-tim

...

<module name="tim-announcement" version="<at:var at:name="SAKAI_VERSION" />" @SAKAI_VERSION@" group-id="org.sakaiproject"/>

...

Promote inner classes to top level classes

coming soonThe Sakai source code has many Java classes which contain inner classes. Inner classes present a problem for Terracotta clustering, when the desire is to cluster/share the inner class, while NOT cluster/sharing the outer class. The reason this problem exists, is that inner classes contain an implied reference to their outer class. This implied reference is just like a member field reference from the Terracotta point of view. Yet, there does not exist any Java syntax to mark this implied reference as transient.

In order to support this code, one of two solutions must be chosen. Either the inner class must be made static, therefore eliminating the implied reference to the other class, or the inner class must be refactored to a top level class. It is recommended the inner class be refactored to a top level class. If the class is left as a static inner class, the outer class can directly reference the inner class fields, without using a mutator method. This is a common Terracotta problem (see this problem documented on the Terracotta web site here). To avoid this pitfall, the simplest solution is to make the fields private and only provide accessor methods. However, in the case of inner classes, private does not mean anything to the outer class. Therefore there is no Java syntax to prevent you from doing the wrong thing accidentally. However, making the inner class a top level class, will provide you with a Java compile time check against accidentally accessing a private field directly.

It is strongly recommended to promote any cluster-enabled inner class to a top level class, if the existing outer class is not going to be cluster enabled.

Retest and Repeat

After you have added the class for instrumentation, checked for transient fields, created a mechanism for resolving transient fields and promoted an inner class to top level class (if necessary), then it is time to retest. Rerun the build process to create your tool's TIM and rerun the terracotta-config build to deploy the tc-config.xml and TIMs. Test your tool again. If you still see exceptions repeat the process. This is one iterative way to work your way through cluster enabling a Sakai tool.