In Computer Science, synchronization refers to relationships among events. For example:

• Serialization: Event A must happen before Event B.
• Mutual Exclusion: Event A and Event B must not happen at the same time.

Java’s support for synchronization is based on implicit locks by the use of synchronized keyword. Every object has an intrinsic lock associated with it. When a thread invokes a synchronized non-static method, it acquires the intrinsic lock for that method’s object. The lock is returned when the method returns (even due to an uncaught exception). Similarly, every class has an intrinsic lock associated with it. A thread acquires this class lock to invoke a synchronized static method and releases when the method returns. These locks are acquired and released automatically.

In addition to intrinsic locks, each instance also has a wait set associated with it. When a thread invokes wait() (or any overloaded wait(...) methods) it is placed in this wait set. The wait(...) methods must be called from a synchronized block. This is used in scenarios like when a thread obtains the lock but is not ready to proceed code in the critical section.

Implicit locks demo

I will demonstrate implicit locks by implementing a solution to producer-consumer problem. Source code is attached as a link at the end of the article. The producer-consumer problem can be described as follows. There are M threads producing items and N threads consuming items. They share a common buffer for transfering these items. The problem is to make sure that producers won’t add items when the buffer is full and consumers won’t remove items from an empty buffer. In ImplicitLocksDemo class I have 3 nested classes – Producer, Consumer and Drop (shared buffer). Producer and Consumer are implemented as threads. Producer creates a String object and places in the drop object which is shared between producers and consumers as shown below:

22
23
24
25
26
27
28
29
30
31
32
33

	public static void main(String s[]) {
		Drop drop = new Drop();
		Consumer c1 = new Consumer("C1", drop);
		Producer p1 = new Producer("P1", drop);
		Consumer c2 = new Consumer("C2", drop);
		Producer p2 = new Producer("P2", drop);
 
		new Thread(p1).start();
		new Thread(c1).start();
		new Thread(p2).start();
		new Thread(c2).start();
	}

To make the problem a bit more complicated, the shared buffer is made to hold only one item. The Drop class has one member variable (shared) which will be set by a producer. Additionally, the Drop class has a variable called empty which tells if the buffer is full or empty. Producers can only set shared with an item when empty is true. Similarly, consumers can only read shared when empty is false. The Drop class has two methods called get() which the consumers call to read an item and a method called set(String) which is called by producers to set an item. Both get() and set() are made synchronized so only one thread can invoke get() or set() method at any time.

Now, what if a producer acquired a lock and wants to invoke set() method and the buffer is not empty? If a consumer had not read the item produced previously, the producer would be overwriting the item. To use the locks effectively, we use wait/notify mechanism provided by Java. wait() and notify are methods defined in Object class, hence, they are available to any class. Invoking wait() makes the current thread go into a waiting state or into the wait set associated with the object on which wait() was invoked. When a consumer reads the item it invokes notify() on drop object which sends a signal to all threads waiting in the wait set of drop object. That is to say that the shared object is now empty and a producer can safely fill the shared storage. So with the help of wait/notify, threads can effectively communicate with each other and share the critical sections in a safe manner. Complete solution is given below.

/**
 * @(#)ImplicitLocksDemo.java	Feb 26, 2008
 */
package lock;
 
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
 
/**
 * Demonstrates Producer and Consumer with a
 * 
 * @author $Author: vijaykandy $
 * @version $Revision: 1.4 $
 */
public class ImplicitLocksDemo {
	/**
	 * Main.
	 * 
	 * @param s
	 */
	public static void main(String s[]) {
		Drop drop = new Drop();
		Consumer c1 = new Consumer("C1", drop);
		Producer p1 = new Producer("P1", drop);
		Consumer c2 = new Consumer("C2", drop);
		Producer p2 = new Producer("P2", drop);
 
		new Thread(p1).start();
		new Thread(c1).start();
		new Thread(p2).start();
		new Thread(c2).start();
	}
 
	/**
	 * Shared class
	 * 
	 * @author $Author: vijaykandy $
	 * @version $Revision: 1.4 $
	 */
	static class Drop {
		private String shared;
 
		private boolean empty = true;
 
		/**
		 * Takes a message when a signal is received.
		 * 
		 * @return
		 */
		public synchronized String get() {
			while (empty) {
				try {
					this.wait();
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
			String message = shared;
			empty = true;
			this.notifyAll();
			return message;
		}
 
		/**
		 * Sets a message when a signal is received.
		 * 
		 * @param s
		 */
		public synchronized void set(String s) {
			while (!empty) {
				try {
					this.wait();
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
			shared = s;
			empty = false;
			this.notifyAll();
		}
	}
 
	/**
	 * Produces a message
	 * 
	 * @author $Author: vijaykandy $
	 * @version $Revision: 1.4 $
	 */
	static class Producer implements Runnable {
 
		private String name;
 
		private Drop drop;
 
		private Random random = new Random();;
 
		private List<String> messages = new ArrayList<String>() {
			{
				add(Integer.toHexString(random.nextInt(1000)));
				add(Integer.toHexString(random.nextInt(1000)));
				add(Integer.toHexString(random.nextInt(1000)));
				add("DONE");
			}
		};
 
		public Producer(String name, Drop drop) {
			this.name = name;
			this.drop = drop;
		}
 
		public void run() {
			Random random = new Random();
			for (String msg : messages) {
				drop.set(msg);
				System.out.format("%s produced: %s%n", name, msg);
				try {
					Thread.sleep(random.nextInt(1000));
				} catch (InterruptedException e) {
				}
			}
		}
	}
 
	/**
	 * Consumes a message
	 * 
	 * @author $Author: vijaykandy $
	 * @version $Revision: 1.4 $
	 */
	static class Consumer implements Runnable {
 
		private String name;
 
		private Drop drop;
 
		public Consumer(String name, Drop drop) {
			this.name = name;
			this.drop = drop;
		}
 
		public void run() {
			Random random = new Random();
			while (true) {
				String message = drop.get();
				System.out.format("%s received: %s%n", name, message);
 
				if (message.equals("DONE")) {
					return;
				}
 
				try {
					Thread.sleep(random.nextInt(1000));
				} catch (InterruptedException e) {
				}
			}
		}
	}

The synchronized keyword can also be used with a block. In this case, threads are required to acquire the lock associated with the object in the synchronized statement as shown here:.

public void m() {
	Object anObject = ...
	// ...
	synchronized(anObject) { // threads must acquire anObject's lock
	}
	// ...
}

Finding the maximum or longest increasing subsequence (LIS) within a given a set of numbers is a classic Computer Science problem. The algorithm is central to many tools and is used in various disciplines related to mathematics, physics etc. In the field of Bioinformatics, LIS is used to find DNA subsequences matching a certain criteria. By recognizing certain patterns in DNA sequences scientists can determine diseases, genetic disorders etc.

Problem

Given a sequence of N integers, find the longest strictly increasing subsequence. For example in the sequence 56, 21, 33, 22, 34, 78, 11, 35, 46, the longest increasing subsequence is 21, 33, 34, 35, 46. In this context we will consider a NXN matrix of integers and find a sequence which is simply a series of adjacent squares. A square may not be used more than once. In the following 10 X 10 grid:

  | 0  1  2  3  4  5  6  7  8  9
--+------------------------------
0 | 95 47 30 36 60 31 57 66 12 55
1 | 35 57 41 13 82 80 71 93 31 62
2 | 89 36 98 75 91 24 95 53 37 99
3 | 25 45 26 17 15 84 80 73 96 21
4 | 75 22 43 96 96 36 64 31 45 86
5 | 45 99 68 74 54 14 93 17 14 55
6 | 14 42 52 54 34 50 22 84 32 41
7 | 90 44 73 10 71 84 20 12 55 52
8 | 95 33 25 31 76 45 44 84 90 52
9 | 94 64 95 24 41 63 87 93 79 12

the longest increasing subsequence is of length 8 consisting of entries 24, 25, 33, 44, 52, 68, 74, 96 as highlighted in red.

Solution

Each number and its position in the sequence are stored in an array. In the first pass, neighbors for each item in the array are found and are stored along with the item. Items are then sorted by their descending value. In the second and final pass, weights are assigned to the neighbors. The neighbor with the least value is assigned weight 1, the next highest neighbor is assigned 2 and so on. To get the longest increasing subsequence, find the element with the highest weight and print its neighbors in the descending order of weights.

Unzip the attachment and cd into the newly created folder. Compile the classes run as follows:

C:\MaximumIncreasingSubsequence>javac -d bin src\*.java
 
C:\MaximumIncreasingSubsequence>java -classpath bin MaximumIncreasingSubsequence small-grid.txt
(24, 0) with value 129 (weight = 15)
(24, 1) with value 138 (weight = 14)
(25, 2) with value 167 (weight = 13)
(25, 3) with value 236 (weight = 12)
(25, 4) with value 300 (weight = 11)
(26, 4) with value 338 (weight = 10)
(27, 5) with value 438 (weight = 9)
(28, 4) with value 469 (weight = 8)
(27, 4) with value 596 (weight = 7)
(27, 3) with value 709 (weight = 6)
(26, 2) with value 723 (weight = 5)
(27, 1) with value 778 (weight = 4)
(28, 1) with value 866 (weight = 3)
(27, 0) with value 939 (weight = 2)
(26, 0) with value 953 (weight = 1)
Program took: 380 milliseconds

Attachments

Source code

Introduction

This article discusses how to install and configure Apache 2.0.x and Tomcat (or JBoss) to communicate with each other via mod_jk. This article also discusses how to setup a Tomcat cluster using mod_jk to balance work load.

Install JDK

1. Download JDK rpm and launch the executable by running the following commands:

   chmod a+x j2sdk-1_4_2_<version number>-linux-i586-rpm.bin
   ./j2sdk-1_4_2_<version number>-linux-i586-rpm.bin

2. Type yes and agree to the binary license agreement.
3. Become root by running su and entering root password
4. Install the rpm. This will install JDK at /usr/java/j2sdk-1.4.2:

   rpm -iv jdk-1.4.2_<version number>.i386.rpm

5. Edit PATH environment variable to include bin directory of JDK by adding the following lines to /etc/profile:

   JAVA_HOME=/usr/java/j2sdk-1.4.2_<version number>
   export JAVA_HOME
   PATH=$JAVA_HOME/bin:$PATH

Avoid Firewall and Routing issues

1. Disable the default firewall (unless you can configure it to allow multicast packets)

   /etc/init.d/iptables stop
   /etc/init.d/ip6tables stop

2. Add this multicast route:

   /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth<id>

Install Apache

1. Download httpd-2.0.50-i686-pc-linux-gnu.tar.gz into a temporary location and run the following commands to install Apache at /usr/local/share:

   unzip < httpd-2.0.50-i686-pc-linux-gnu.tar.gz | tar xvf -
   cd httpd-2.0.50
   ./install-bindist.sh /usr/local/share/apache-2.0.50

2. Edit PATH environment variable to include bin directory of Apache by adding the following lines to /etc/profile:

   APACHE_HOME=/usr/local/share/apache-2.0.50
   export APACHE_HOME
   PATH=$APACHE_HOME/bin:$PATH
   export PATH

Install Tomcat

1. Move apache-tomcat-x.y.z.zip.zip to /usr/local/share (I will refer to the installation folder by this path) and unzip it:

   unzip apache-tomcat-x.y.z.zip

2. Edit PATH environment variable to include bin directory of Apache by adding the following lines to /etc/profile:

   TOMCAT_HOME=/usr/local/share/apache-tomcat-x.y.z
   export TOMCAT_HOME
   PATH=$TOMCAT_HOME/bin:$PATH
   export PATH

Configure mod_jk

1. Copy the mod_jk binary to $APACHE_HOME/modules directory and rename it as mod_jk.so
2. Add the following lines at the very bottom in $APACHE_HOME/conf/httpd.conf
   
   

   #Include mod_jk configuration file
   Include conf/mod-jk.conf

3. Under $APACHE_HOME/conf create mod-jk.conf and write the following lines in it:
   
   

   # Load mod_jk module
   # Specify the filename of the mod_jk lib
   LoadModule jk_module modules/mod_jk.so
   # Where to find workers.properties
   JkWorkersFile conf/workers.properties
   # Where to put jk logs
   JkLogFile logs/mod_jk.log
   # Set the jk log level [debug/error/info]
   JkLogLevel info
   # Select the log format
   JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
   # JkOptions indicates to send SSK KEY SIZE
   JkOptions +ForwardKeySize +ForwardURICompat -
   ForwardDirectories
   # JkRequestLogFormat
   JkRequestLogFormat "%w %V %T"
   JkMount /Context/* loadbalancer

   
   
   Where Context is the web-app context name.

4. Under $APACHE_HOME/conf create workers.properties and populate it as follows:
   
   

   # Worker list
   worker.list=loadbalancer
   # Define Node1
   worker.node1.port=8009
   worker.node1.host=node1.ip.address
   worker.node1.type=ajp13
   worker.node1.lbfactor=1
   #worker.node1.local_worker=1 (1)
   worker.node1.cachesize=10
   # Define Node2
   worker.node2.port=8009
   worker.node2.host=node2.ip.address
   worker.node2.type=ajp13
   worker.node2.lbfactor=1
   #worker.node2.local_worker=1 (1)
   worker.node2.cachesize=10
   # Load-balancer
   worker.loadbalancer.type=lb
   worker.loadbalancer.balanced_workers=node1, node2
   worker.loadbalancer.sticky_session=1
   worker.loadbalancer.local_worker_only=1

   Add one worker per node and name workers as node1, node2, node3 … nodeN. Don’t forget to define all these as load balancing workers:

   worker.loadbalancer.balanced_workers=node1, node2, node3, ... nodeN

   Replace node1.ip.address with IPAddress of Tomcat(or JBoss) instance1 and so on. The attribute sticky_session=1 tells mod_jk that SESSION ID’s should be routed back to the same Tomcat worker. The lbfactor determines the number of requests a worker receives. The higher the lbfactor the more requests a worker receives.

5. Each node should be named according to the names specified in workers.properties. On each Tomcat instance, edit $TOMCAT_HOME/conf/server.xml. Locate the <Engine> element and add an attribute called jvmRoute:

   <Engine name="Catalina" defaultHost="localhost" jvmRoute="node1">
   …
   </Engine>

NOTE: THE jvmRoute ATTRIBUTE MUST MATCH THE NAME SPECIFIED IN workers.properties.

Start Apache and Tomcat

1. Start Apache:

   $APACHE_HOME/bin/apachectl -k start

2. To stop use:

   $APACHE_HOME/bin/apachectl -k stop

3. Start Tomcat:

   $TOMCAT_HOME/bin/startup.sh

4. Stop Tomcat:

   $TOMCAT_HOME/bin/shutdown.sh

Introduction

This article discusses JMS architecture and various components within a JMS system. Message models and messaging styles are explained. The article also discuses synchronous and asynchronous message consumption.

JMS Architecture

JMS (as defined in JMS specification version 1.1) is a set of interfaces and associated semantics that provides a common way for Java programs to create, send, receive and read an enterprise messaging system’s messages. In this context messages are asynchronous requests, reports or events that are consumed by enterprise applications, not humans. They contain precisely formatted data that describe specific business actions.
A JMS application is composed of the following parts:

• JMS Clients: These are Java programs that send and receive messages. For example, Message Driven Beans.
• Messages: The information transferred between the clients.
• JMS Provider: The messaging system that implements JMS specification. JBossMQ is an example.
• Administered Objects: These are pre-configured JMS objects used by the clients. There are two types of administered objects:
  1. Connection Factory: Client uses this object to create a connection with a provider.
  2. Destination: Client uses this object to specify the destination of messages it is sending or the source of messages it receives.

Message Model

Messages are lightweight entities that consist of a header and a body. The header contains fields used for message routing and identification. The body is the payload which clients exchange.

Header { 
   jmsDestination  : QUEUE.KSIDemoQueue
   jmsDeliveryMode : 2
   jmsExpiration   : 0
   jmsPriority     : 4
   jmsMessageID    : ID:29-12015475384804
   jmsTimeStamp    : 1201547538480
   jmsCorrelationID: null
   jmsReplyTo      : null
   jmsType         : null
   jmsRedelivered  : true
   jmsProperties   : {JMS_JBOSS_REDELIVERY_COUNT=2}
   jmsPropReadWrite: false
   msgReadOnly     : true
   producerClientId: ID:29
}

  JMSType:         null
  JMSDeliveryMode: 2
  JMSExpiration:   0
  JMSPriority:     4
  JMSMessageID:    ID:414d5120445149434d5320202020202046f2d24b2001c001
  JMSTimestamp:    1201106363820
  JMSCorrelationID:null
  JMSDestination:  queue:///QUEUE.KSIDemoQueue
  JMSReplyTo:      null
  JMSRedelivered:  false
  JMS_IBM_PutDate: 20080123
  JMSXAppID:       Websphere MQ Client for Java
  JMS_IBM_Format:  MQSTR   
  JMS_IBM_PutApplType:28
  JMS_IBM_MsgType: 8
  JMSXUserID:      mqm         
  JMS_IBM_PutTime: 16392943
  JMSXDeliveryCount:1

Header fields are discussed below.

Header field

JMSDestination

JMSDeliveryMode

JMSMessageID

JMSTimestamp

JMSCorrelationID

JMSReplyTo

JMSRedelivered

JMSType

JMSExpiration

JMSPriority

In addition to these properties, a client can set and get additional properties via setXXXProperty() and getXXXProperty() methods. JMS reserves JMSX property name prefix for JMS defined properties. Most of these JMSX properties are dependant on a JMS provider.

JMS provides five forms of message body. All messages extend Message interface.

1. StreamMessage This message is composed of Java primitive values. It is written and read sequentially
2. MapMessage This message contains a set of key-value pairs where keys are Strings and values are Java primitive types
3. TextMessage This is the commonly used message form. This message body contains a java.lang.String. For e.g., clients and exchange XML data using this type.
4. ObjectMessage This message allows for transfer of a Serializable Java object.
5. BytesMessage This message is composed of bytes.

The difference between StreamMessage and BytesMessage is that StreamMessage preserves the type information of Java primitive types whereas BytesMessage does not.

Introduction

This article discusses how to configure Apache and OpenSSL to serve https content. We assume Apache is installed and OpenSSL commands are available in the PATH environment variable. Otherwise install Apache and OpenSSL using yum or apt.

Create a working directory

Let’s call it sslcert:

$mkdir sslcert

Create two subdirectories under it

Create 2 subdirectories under sslcert. Let’s call them certs and private.

$cd sslcert
$mkdir certs private

Create a database to keep track of each certificate signed

Run the following commands:

$echo '01' > serial
$touch certindex.txt

Make a custom config file for openssl to use

Copy the config elements into a file called openssl.cnf. (edit as needed):

Boggle is a word game designed by Allan Turoff. The objective of the game is to construct as many different words as you can from a grid of letters. You can use letters (in positions) that are next to each other – above, below, left, right, diagonal but you can not use the same letter more than once. Each word must be defined in a dictionary. Points are assigned according to the length of the word.

The source code attached here is an implementation of this game in Java. It demonstrates recursion to solve problems like this game. The program attempts to construct words as defined in dic.txt from puzzle.txt. Points are assigned according to the length of the word.

Instructions

To run this program you need JDK 5 or better installed. You can get JDK from here.

1. Unzip the file. This creates a folder called Boggle
2. Compile the code: javac src\*.java -d bin
3. Run the program: java -classpath bin Boggle

C:\Boggle>javac src\*.java  -d bin
 
C:\Boggle>java -classpath bin Boggle
Enter boggle file:
puzzle.txt
Opened puzzle.txt
Enter dictionary name:
dic.txt
Opened dic.txt
Reading files...
Solving...
Word            | Points | Path
----------------+--------+-----------------------
            APR |      1 | [(0,0), (0,1), (0,2)]
      APRTOCFED |     15 | [(0,0), (0,1), (0,2), (1,2), (1,1), (1,0), (2,0), (2,1), (2,2)]
            COT |      1 | [(1,0), (1,1), (1,2)]
            FED |      1 | [(2,0), (2,1), (2,2)]

Attachments

Source code

Introduction

This article assumes you have some understanding of JMS internals. If not, you might want to start here. Here we describe what reliability means and how to build reliable JMS applications. To understand the source code you must be familiar with EJBs, XDoclet and Ant. The application used in the article showcases some nifty features like message selectors, dependancy injection via Xdoclet and Ant, EJB ENC etc.

Reliability

Reliability in computer science can be summed up in four words – Atomicity, Consistency, Isolation, Durability (ACID). We will examine each of these properties and build a JMS application by applying them. For the purpose of demostration let’s build a MessageConsumer that receives only even numbers. We begin with a MessageDrivenBean. The source code discussed here is attached to this article.

We create a new class called DemoBean and implement MessageDrivenBean and MessageListener. We inherit EJB behavior from MessageDrivenBean. The tags on top of the class are XDoclet tags which help us automatically create deployment descriptor files required by the EJB container. For more information on how to use Xdoclet please see here.

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

/**
 * A simple message consumer
 * 
 * @ejb.bean name="DemoBean" display-name="Demo MDB to demonstrate JMS features"
 *           jndi-name="ejb/Demo" description="Listens to 'Demo' messages"
 *           destination-type="javax.jms.Queue"
 *           acknowledge-mode="Auto-acknowledge"
 *           transaction-type="Container"
 *           message-selector="Type='Even'"
 * 
 * @ejb.env-entry name="MAX_RETRIES" type="java.lang.Integer"
 *                value="${max.request.retries}" description="If an application
 *                error occurs, message will be rolled back to the Queue and
 *                retried this many times."
 * 
 * @jboss:destination-jndi-name name="${jndi.queue.name}"
 * @websphere.mdb listenerPort="${jndi.queue.listener}"
 */
public class DemoBean implements MessageDrivenBean, MessageListener {
	private static final long serialVersionUID = -6540893609236685101L;
 
	private MessageDrivenContext messageDrivenContext = null;

The following simple ant target creates all necessary boilerplate code.

130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145

<target name="ejbdoclet" description="Generates deployment descriptors etc.">
	<taskdef name="ejbdoclet" classname="xdoclet.modules.ejb.EjbDocletTask">
		<classpath refid="project.classpath" />
	</taskdef>
	<ejbdoclet ejbSpec="2.0" destDir="${gensrc.dir}">
		<fileset dir="${src.dir}">
			<include name="**/*Bean.java" />
		</fileset>
		<deploymentdescriptor destDir="${ejb.descriptors.dir}">
		</deploymentdescriptor>
		<websphere destDir="${ejb.descriptors.dir}">
		</websphere>
		<jboss Version="3.0" destDir="${ejb.descriptors.dir}">
		</jboss>
	</ejbdoclet>
</target>

The @ejb.bean tag in the Java class creates the following code in ejb-jar.xml file.

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

<message-driven >
 <description><![CDATA[Listens to 'Demo' messages]]></description>
 <display-name>Demo MDB to demonstrate JMS features</display-name>
 
 <ejb-name>DemoBean</ejb-name>
 
 <ejb-class>com.ksi.demo.ejb.DemoBean</ejb-class>
 
 <transaction-type>Container</transaction-type>
 <message-selector><![CDATA[Type='Even']]></message-selector>
 <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
 <message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
 </message-driven-destination>
 
 <env-entry>
    <description><![CDATA[If an application error occurs, message will be rolled back to the Queue and retried this many times.]]></description>
    <env-entry-name>MAX_RETRIES</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value><![CDATA[4]]></env-entry-value>
 </env-entry>
 
</message-driven>

The transaction-type tag in the ejb-jar file lets the EJB container start and manage transactions for us. The message-selector tag lets the Connection know that only messages assigned a property ‘Type’ and its value ‘Even’ be sent to this bean. The tag subscription-durability tells the JMS Container to persist the messages in case of a container failure. In addition to these we create an variable (available only in the ENC of this bean) called MAX_RETRIES.

As you may have noticed the values of MAX_RETRIES, jboss destination-jndi-name and websphere.mdb listenerPort are enclosed in ${}. These are properties defined in build.properties available to Ant. Ant populates these to generate ejb-jar file. We inject this depedancy at run time. We will discuss MAX_RETRIES later. Since we implement MessageListener, we inherit onMessage() method. When a message arrives in a queue, the JMS container invokes the onMessage() of MDB to pass the message object.

103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

/**
 * This is called when there is a message in the Queue.
 * 
 * @ejb.transaction type="Required"
 */
public void onMessage(Message msg) {
	try {
		System.out.println("Message:" + msg);
 
		MapMessage message = (MapMessage) msg;
 
		Enumeration e = message.getMapNames();
		Hashtable data = new Hashtable();
		while (e.hasMoreElements()) {
			String key = (String) e.nextElement();
			String val = message.getString(key);
			data.put(key, val);
		}

Since the client posts a MapMessage, we cast the generic Message interface to MapMessage and retrieve data stored in the map. This is the basic work flow of a JMS application. You can run ant, deploy the EAR file in JBoss or WebSphere to test this behavior.

Atomicity

Atomicity refers to the ability of JMS application to gaurantee that all tasks within a transaction are performed or none at all. A transaction is a group of tasks that run as one single unit of work. In other words all the tasks are performed successfully or none at all. So when a failure occurs (OutOfMEmoryErrors, connection failures etc.) tasks in a transaction are undone from where the failure occurred. In this scenario, tasks that need to be performed are the following:

1. Receive message from the queue
2. Print the payload in message (the even number)
3. Acknowledge that message was received and that all processing was done

For our bean to be reliable, we require all these tasks to be performed. In other words, message needs to be processed atomically. When a failure occurs while message is being processed, we would like to put the message back in the queue so it can be picked up again for processing (hopefully after the cause of the failure has been fixed). This process is called a rollback. There are two ways a transaction can be performed in a EJB container:

• by the MDB (Bean Managed Transaction)
• by the container (Container Managed Transaction)

In Bean Managed Transaction, as the name suggests, the bean is responsible for the three tasks. However, message receipt (first task) that causes the bean to be invoked is not part of the transaction. An example of bean managed transaction.

public void onMessage(Message msg) {
	UserTransaction ut = messageDrivenContext.getUserTransaction();
	try {
		ut.begin();
		System.out.println("Message:" + msg);
 
		MapMessage message = (MapMessage) msg;
 
		Enumeration e = message.getMapNames();
		Hashtable data = new Hashtable();
		while (e.hasMoreElements()) {
			String key = (String) e.nextElement();
			String val = message.getString(key);
			data.put(key, val);
		}
		ut.commit();
	} catch (Exception ex) {
		try {
			ut.rollback();
		} catch (SystemException e) {
			throw new EJBException("Rollback failed" + e.getMessage());
		}
		throw new EJBException ("Transaction failed: " + e.getMessage());
	}
}

The following picture shows demarcation of a baen managed transaction.

Figure showing boundaries of a bean managed transaction

Since this is not what we want, we request the EJB container to manage transactions for us. The transaction-type tag in the ejb-jar file does exactly this. The EJB container’s transaction manager gaurantees that message will be delivered to the MDB, and when the processing is done, automatically acknowledges the JMS container which then discards the message. If for some reason an acknowledgement is not sent, the JMS container resends the message to the MDB.

Figure showing boundaries of a container managed transaction

Hence the three steps are executed as one unit of work or in other words atomically.

Consistency

Consistency refers to the property of an application being in a legal state when the transaction begins and when it ends. This means that a transaction moves the state of entities from one consistent state to another. For an application to be reliable, when a problem occurs the application needs to revert to the last consistent state. In this DemoBean, lets simulate a failure condition by throwing an exception at random.

122
123
124
125
126
127

// Randomly throw an exception so that the message will be rolled
// back.
Random random = new Random();
if (random.nextInt(3) == 1) {
	throw new JMSException("Something bad happened!");
}

There are two things we can do to revert to a previous consistent state: (a) re-throw the exception to let the transaction manager know that there has been a problem or (b) do not acknowledge the message. Re-throwing an exception automatically rolls the transaction back which puts the message back in the queue. This is the advantage of using an MDB. However, if the problem persists, we keep getting into the same failure scenario. So this does not help a lot. We want to be able to control the rollback process so that the same message is not tried repeatedly draining the resources. For this reason we write a method to control the rollback process:

130
131
132

	} catch (JMSException e) {
		rollback(msg, e);
	}

Inside the rollback() method we check for Delivery Count in the header field. In JBoss this field is JMS_JBOSS_REDELIVERY_COUNT and in WebSphere this is JMSXDeliveryCount. If the message has been delivered more than MAX_RETRIES times, instead of rolling the message back we send an email to a human agent. MAX_RETRIES is a variable available in the Environment Naming Context of this bean. Is is injected at build time using Ant.

147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169

	try {
		InitialContext context = new InitialContext();
		maxRetries = (Integer) context.lookup("java:comp/env/MAX_RETRIES");
	} catch (NamingException e2) {
		System.out.println(e2.getMessage());
	}
 
	try {
		if (message.propertyExists("JMSXDeliveryCount")) {
			retryAttempt = message.getIntProperty("JMSXDeliveryCount");
		}
	} catch (JMSException e2) {
 
	}
 
	try {
		String messageID = message.getJMSMessageID();
 
		if (retryAttempt < maxRetries.intValue()) {
			messageDrivenContext.setRollbackOnly();
			System.out.println("Message " + messageID + " rolledback due to " + cause.getMessage());
		} else {
			TextMessage textMessage = (TextMessage) message;

Since the exception is processed gracefully, the transaction manager correctly assumes that the message processing was successful and automatically acknowledges the JMS container.

Isolation

Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. According to the EJB Specification version 2.1, transactions not only make completion of a unit of work atomic, but they also isolate the units of work from each other, provided that the system allows concurrent execution of multiple units of work. Hence we are guranteed that an invocation of onMessage() method has no impact on invocation of onMessage() on another MDB instance. Note that an EJB container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. The isolation level describes the degree to which the access to a resource manager by a transaction is isolated from the access to the resource manager by other concurrently executing transactions. For more information on isolation levels please see Sun’s J2EE tutorial.

Durability

Durability refers to the guarantee that a successful transaction will persist and can not be undone. JMS supports two modes of message delivery.

1. The NON_PERSISTENT mode is the lowest-overhead delivery mode because it does not require that the message be stored in a stable storage. A JMS provider failure can cause a NON_PERSISTENT message to be lost.
2. The PERSISTENT mode instructs the JMS container to take extra care to insure the message is not lost in transit due to a JMS provider failure.

Delivery mode is set to PERSISTENT by default. JMS providers never produce duplicate messages. This means that a producer that produces a message can rely on the JMS container to insure that consumers of the message (MDB) will receive it only once. No client error can cause a provider to duplicate a message.

Attachments

Source code
Unzip and run ant in the project’s root folder.