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 5 of 7

Statelessness and scalability

The use of stateless objects can help scale an application in a distributed computing environment like the cloud because work can be load balanced onto whatever machine is most suited to do it. You don't have to worry about contention for a single instance of an object (as in Figure 4), a situation that could potentially lead to race conditions, deadlock, and starvation; instead, you can just add more machines and let the work scale out horizontally onto them. If you are dependent on a single, golden instance of a stateful object, and that instance may be wanted by many concurrent calls, then, depending on the stateful model you're using, you may be creating a scalability bottleneck. However, no matter what stateful model you use, you are still introducing more overhead than you would see in a stateless model.

Statelessness and availability

If your cloud environment is free to use any machine to get its work done, then you have very widespread availability (as in Figure 3). In case of failure, the loss of any machine does not affect you, provided you have enough machines to continue; this is illustrated in Figure 6.

Stateless objects promote availability and reliability

Figure 6. Stateless objects promote availability and reliability. (Click to enlarge.)

Again, if you are dependent on a single, golden instance of a stateful object, and the resources holding that instance go down, you have now lost availability for that instance of that object, and have to reconstitute it elsewhere, if possible, hopefully without loss of state; this is illustrated in Figure 7. At a minimum, you have introduced complexity into your application.

Stateful objects reduce availability, and may reduce reliability

Figure 7. Stateful objects reduce availability, and may reduce reliability. (Click to enlarge.)

Statelessness and load balancing

If the cloud environment is free to use any machine to get work done, then whatever machine has the least overhead can be given the work. (This is illustrated in Figure 3.) If there is a single, golden instance of an object on a single machine, and it is getting all the attention from calling clients, then you may have both a load balancing problem and a resource contention problem (as shown in Figure 5). The model of statefulness you use will determine the severity and complexity of the problem, and determine whether or not you can spread the work to multiple machines sharing a cache of the same stateful instance of the object.

Statelessness and reliability

The stateless model also bolsters a cousin of availability: reliability. Statelessness, coupled with a self-healing cloud environment, affords a lot of flexibility. If a machine goes down in such an environment due to hardware failure, the work can continue with another instance of the object on another machine (as shown in Figure 6). You wouldn't have to worry about loss of consistency or other complexity as you would if you had depended on a stateful object that has been lost.

Statelessness and concurrency safety

Stateful code in any form in a distributed or parallel environment requires being mindful of concurrency issues. Stateless code, on the other hand, is more likely (no guarantees, of course) to be concurrency safe as you execute it across distributed nodes, or across multiple threads and cores. Stateless code is also in most cases easier to execute across multiple processes instead of multiple threads, a model seen in Google's Chrome and Microsoft's Internet Explorer 8 browsers, where each tab is a process and not a thread.

Concurrency safety is a complex topic; rather than rambling on myself, I'll point you to a great article by Brian Goetz. According to Goetz, "many Web applications that use HttpSession for mutable data (such as JavaBeans classes) do so with insufficient coordination, exposing themselves to a host of potential concurrency hazards." There's lots of that kind of code already out there, and it just gets more complex in distributed and multicore parallel applications.

  • Print
  • Feedback

Resources