~pperalta

This week I’m in Orlando for Collaborate 09 to give a talk on Oracle Application Grid which includes Coherence. If anyone in Orlando wants to get together this week give me a shout.

Yesterday I had the chief Coherence architect review some of my code before submitting it to Perforce. (No it wasn’t done by Cameron.) I actually look forward to them because I always learn something new. This time what stuck with me was the refactoring of a method and the before/after difference.

Here’s the before:

protected void configureAffinitySuffix()
    {
    String sJvmRoute = m_sConfiguredJvmRoute;
 
    if (sJvmRoute != null)
        {
        CacheFactory.log("jvmRoute set to '" + sJvmRoute + "' via configuration", 6);
        }
    else
        {
        sJvmRoute = getJvmRouteViaJmx();
        if (sJvmRoute == null)
            {
            m_sAffinitySuffix = "";
            CacheFactory.log("jvmRoute is not configured", 6);
            }
        }
 
    if (sJvmRoute != null)
        {
        CacheFactory.log("Configured affinity suffix: " + sJvmRoute, 4);
        m_sAffinitySuffix = SUFFIX_SEPARATOR + sJvmRoute;
        }
    }

Including blank lines, this is a 24 line method; and it isn’t very complex at all. Here is the newly refactored version:

protected void configureAffinitySuffix()
    {
    String sJvmRoute = m_sConfiguredJvmRoute;
    if (sJvmRoute == null)
        {
        sJvmRoute = getJvmRouteViaJmx();
        }
 
    if (sJvmRoute == null)
        {
        m_sAffinitySuffix = "";
        CacheFactory.log("The jvmRoute setting is not configured", 3);
        }
    else
        {
        m_sAffinitySuffix = SUFFIX_SEPARATOR + sJvmRoute;
        CacheFactory.log("Configured affinity suffix: " + sJvmRoute, 3);
        }
    }

The main differences are:

• The new method is 19 lines, reduced from 24
• All of the if statements are consistent; they’re all testing for a positive comparison
• There are no nested blocks
• The logging is more consistent, both in the ordering (the logging appears after the relevant line of code) and in the log level. There is also less logging so as to prevent the logs from filling up with noise.

All in all, we didn’t change the functionality of this method at all; however it is much cleaner and easier to follow. This is the attention to detail that IMHO is a significant factor in the quality of Coherence. (BTW, all submissions are peer reviewed before checking into source control.)

Anyone that follows me may have noticed no updates for the past few days. Somehow my account (http://twitter.com/patrickperalta) stopped working without any clue as to what could be the cause. Since I can’t log in to report a trouble ticket, I’ve sent an email to support at twitter.com, but I’m not holding my breath for a response anytime soon.

Strange thing is that I can still read updates from those that I’m following through Tweetie and TwitterFon, but no updates from me.

This Thursday will be the next Coherence SIG in New York. Check out this new Coherence Blog by PM Craig Blitz for more details. I will be talking about POF (the Coherence platform neutral high performance serialization library), including some new features coming out in Coherence 3.5.

Recently I was helping a customer install Coherence*Web on a JSF application. After running the install and deploying the war file, I saw the following exception:

javax.servlet.ServletException: Error while saving state in 'session': 'session attribute for name "/Page1.jsp" does not implement Serializable; class: Class javax.faces.component.UIViewRoot

HTTP session attributes must be serializable in order to place them into a distributed cache. This requirement is not unique to Coherence*Web, any session replication solution will require this in order to replicate sessions to another JVM.

However, Coherence*Web does have a feature that can let you work around this. If you place a non serializable attribute into an HTTP session with sticky session optimization enabled (see description of this feature at the bottom of this link), the attribute will be placed in a local cache (and a warning will be logged.) The idea is that if a sticky load balancer is managing the traffic, the chances are very good that subsequent requests for that session will go to the same JVM which is holding that attribute in memory. Obviously if the load balancer sends the request to another JVM (or if the JVM leaves the cluster) that session attribute will not be available in the request. Therefore this is not a recommended approach; this feature is meant to ease the transition of a web application from a single JVM to a distributed environment.

So it appears that JSF is placing some sort of view metadata into the session that isn’t serializable. The good news is that JSF can be configured to store this data on the client side (as a hidden form field) instead of the server side (in a session.) This change needs to be made in web.xml; change this:

  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>server</param-value>
  </context-param>

to this:

  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
  </context-param>

More information on this setting can be found here:

http://java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/

I do find it odd however that they have the ability to write out the state to the client, but the object that holds this state isn’t serializable for some reason. I wonder if this was an oversight or if this is by design.