Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Building cloud-ready, multicore-friendly applications, Part 1: Design principles

Prepare your applications for the future of distributed computing

By Guerry Semones, JavaWorld.com, 03/03/09

  • Print
  • Feedback

Page 4 of 7

Statelessness

A friend of mine used to say, "All generalizations are false, including this one." Generally, the rule of thumb in distributed computing is that stateful objects are bad, and stateless is good. There are a number of advantages to being stateless on the cloud and in concurrent programming, and you'll see them in detail in this section.

In my discussion of atomicity above, I said that distributing or parallelizing two non-atomic calls, where method A changes state that method B needs, introduces overhead; I noted that if this isn't handled correctly, it can inhibit scalability and availability. Now I'll show you in more detail what scalability and availability mean in the context of statelessness versus statefulness, and add load balancing, reliability, and concurrency safety to the discussion.

Stateless vs. stateful

First, some definitions are in order. A stateless object does not hold information or context between calls on that object. In other words, each call on that object stands alone and does not rely on prior calls as part of an ongoing conversation. A caller could call a method on one instance of a stateless object, and then make a call on a different instance of the same object, and not be able to tell the difference, as illustrated in Figure 2.

A client calls multiple instances of a stateless object without affecting the outcome of the calls

Figure 2. A client calls multiple instances of a stateless object without affecting the outcome of the calls. (Click to enlarge.)

This does not mean that a stateless object does not deal with data or context; rather, such an object simply does not hold that data or context across multiple method calls, and doesn't access it concurrent to other processes, be they distributed processes or local threads or processes. Consequently, multiple callers may access any instance of a stateless object and have their call satisfied, as illustrated in Figure 3.

Multiple clients concurrently call distributed instances of a stateless object

Figure 3. Multiple clients concurrently call distributed instances of a stateless object. (Click to enlarge.)

Statefulness implies certain conditions. Take, for example, a stateful shopping cart object. Each instance of a stateful shopping cart object might represent an individual customer. Therefore, if you had a thousand customers shopping on a site, there would be, in theory, a thousand instances of the stateful shopping cart object. To update the state of a given customer's shopping cart, you must find the correct object for that customer and make calls on it. This is the Neo the One version of statefulness. Only one object can do the job, and Morpheus must find it ... somewhere in the Matrix.

Statefulness may also imply shared state. Shared state may be as simple as an object that is generally stateless in terms of member data (per instance values) and yet can hold onto static data (per class values) that changes from method call to method call, and affects the outcome of subsequent method calls. The static data injects its importance into the conversation between the callers and the object. Shared state gives rise to increased complexity, whether shared across a cloud of computing resources or across local threads or processes.

Therefore, a general definition of statefulness is in order: a stateful object holds onto data, information, or context that is important across the conversation of multiple calls on a given instance of that object (as illustrated in Figure 4), and multiple callers may need concurrent access to that state (as illustrated in Figure 5).

A calling client returning to the same object instance as part of an ongoing stateful conversation

Figure 4. A calling client returning to the same object instance as part of an ongoing stateful conversation. (Click to enlarge.)

Multiple clients concurrently calling a single, stateful instance of an object

Figure 5. Multiple clients concurrently calling a single, stateful instance of an object. (Click to enlarge.)

If an object is stateless, the cloud or the multicore environment is free to use any instance of that object to get its work done (as in Figures 2 and 3). Therefore, any instance of the called object can be Neo. From a design standpoint, this affects scalability, availability, load balancing, and reliability.

  • Print
  • Feedback

Resources