IMultithreadedChannel

IMultithreadedChannel is a multithreaded version of the IChannel API. Each IChannel-like method is accomanied by a String key representing which virtual "instance" of the channel is being called. This allows a single instance of IMultithreadedChannel to take the place of many IChannel instances.

IMultithreadedChannel came into being in 2001.

A problem with IMultithreadedChannel since 2002 is that it is not well understood under what circumstances and why it is appropriate to write an IMultithreadedChannel rather than a basic IChannel. This is something that should be addressed in the JavaDoc for this interface. However, this Wiki page is also a place to collect insight and experience with this API.

IChannel vs. IMultithreadedChannel

Advantages of IChannel

A much simpler API. Easier to avoid common mistakes. You can just use instance variables to hold your state for this particular instance of this particular channel, servicing just one box on one user's screen.

Appropriate resource recovery when a user's session ends can "just happen" – the reference to the IChannel from the session ends, so it is garbage-collectible. (Of course, you can and should recover resources sooner via the session done event). A risk in IMultithreadedChannel is reliance upon proper propogation of that event to drop state from internal maps.

More object-oriented. There's an IChannel instance for each box on each user's screen. Easy to get your brain around.

Advantages of IMultithreadedChannel

Less object creation? A single object instance can service multiple threads.

the interface definition

/* Copyright 2001 The JA-SIG Collaborative.  All rights reserved.
*  See license distributed with this file and
*  available online at http://www.uportal.org/license.html
*/

package org.jasig.portal;

import org.xml.sax.ContentHandler;

/**
 * An interface for multithreaded channels.
 * Multithreaded channels are trusted to keep their own state/session/user 
 * separation (instead of relying on the servlet engine to do so).
 * The methods are exact analogs of those in {@link IChannel} interface, 
 * but means to identify the channel instance are passed along 
 * with each method.
 * Please refer to {@link IChannel} interface for method descriptions.
 * @author Peter Kharchenko <a href="mailto:">pkharchenko@interactivebusiness.com</a>
 * @version $Revision: 1.3 $
 * @see IChannel
 * @see IMultithreadedCacheable
 */

public interface IMultithreadedChannel {

    /**
     * @param uid a string uniqly identifying a channel "instance" in the system.
     * For example, a combination of session id and channel instance id would fit the bill.
     */
    public void setStaticData (ChannelStaticData sd, String uid) throws PortalException;
    public void setRuntimeData (ChannelRuntimeData rd, String uid) throws PortalException;

    public void receiveEvent (PortalEvent ev,String uid);

    public ChannelRuntimeProperties getRuntimeProperties (String uid);
    public void renderXML (ContentHandler out,String uid) throws PortalException;
}

Resources for using IMultithreadedChannel

• In August 2003 Bill Thompson posted some useful abstract classes for using IMultithreadedChannel
• Using a ConcurrentHashMap instead of Collections.synchronizedMap() or other "hard" synchronization on the internal state map can reduce the performance costs and potential deadlock in state map synchronizations while retaining the threadsafety that implementation of IMultithreadedChannel requires.