ScappShots

NCache Concurrency Controls

subuta — Thu, 08 Mar 2012 18:50:31 +0000

Recently I have been looking into .NET-friendly in-memory data grid (IMDG) software. One of the products I have been experimenting with is Alachisoft’s NCache.

When I analyze a distributed caching product, I like to focus first on concurrency control. Before examining performance, scalability, or advanced architectural features, it is valuable to confirm that the software can be used to construct applications that remain reliable when data is shared and subject to updates. To do this I usually construct a test case involving extreme data hot spots, and exercise the features offered by the product for managing data access in these heavy contention situations.

If the product I’m working with offers features for dividing work into ACID style transactions then I explore those features as part of my analysis of concurrent data access. NCache does not provide features for using ACID transactions, so my work with NCache has focused on its locking features.

NCache provides both optimistic and pessimistic concurrency control. The pessimistic locking model turns out to be unusual, at least in my experience. Although the documentation on this feature is quite sparse, with help from the (very responsive) tech. support team at Alachisoft I was able to get an understanding of how NCache’s pessimistic locking works and how to use the NCache API to control it.

Here are some key points about NCache’s pessimistic locking:

1. The NCache data access API provides specialized methods for acquiring locks, releasing locks and accessing items in the cache under locking constraints.

2. Each lock represents the state of an item of data in the cache.

3. Locks are not granted to a thread or a process. Every lock is equally visible to and manipulable by all cache client threads, regardless of which thread originally requested the lock.

4. Locking is completely cooperative. If locking is used to control access to a data item then, to ensure that exclusive access to that item will be maintained until the routine that requested the lock relinquishes it, every potentially concurrent access to that item must be made using the locking form of the NCache data access API. Using a non-locking API method to access a locked item will bypass the lock.

5. In at least one case, using a non-locking API method will not only bypass the lock but will remove it.

6. NCache’s locks will never cause a client thread to block. Data access methods that access a locked item in the cache will return right away. Clients must include logic to interpret the results of the method invocation and retry it if appropriate.

7. In some cases, to determine why a method has not been successful the side effects of the method must be examined.

This final point requires a fuller explanation. Most of the the pessimistic locking API methods take a reference to an object called a LockHandle as one of their arguments. A LockHandle stores the information that identifies a lock on a data item. The values stored in the LockHandle you pass in may be changed by the method. Depending on which method you use and the state (locked or unlocked) of the item you are trying to access, to interpret the results of your locking call it may be necessary to inspect the values in the LockHandle you passed in. Here is an example:

The Get() method takes a key and returns the associated cached item if there is one. The locking form of the Get() method takes three additional arguments, one of which is a LockHandle reference. Depending on the values of those arguments, the method can be used to lock an object and retrieve it in a single call. In this case the method will return null if there is no object in the cache with the specified key value, or if the object exists but is already locked. To distinguish between these two cases the caller must examine the post-call values in the LockHandle.

NCache’s concurrency features work as intended, and with them I was able to maintain the data consistency required by my test scenario. Both the optimistic and the pessimistic features delivered correct results when data items were subject to vigorous concurrent access. However, when compared with the concurrency features provided by well known competitors, NCache’s concurrency controls are quirky and not particularly developer-friendly. Its vulnerability to pessimistic locks being accidentally bypassed or removed by clients that don’t conform to the cooperative lock management protocol makes applications that depend on exclusive data access prone to bugs. The non-blocking approach may be welcome in some situations, but the lack of blocking calls is likely to lead to increased client code complexity and reduced performance in many cases. The lack of support for ACID transactions poses a significant obstacle to building applications that must maintain strict data consistency. For some use cases NCache’s pessimistic locking or its optimistic concurrency features may suffice, but developers designing a system with shared access to writable data should study its concurrency control feature set carefully before choosing NCache.

.NET Support in GigaSpaces XAP

subuta — Fri, 24 Feb 2012 09:43:55 +0000

Introduction

(download PDF version with illustrations)

Some work I did for a client a few months ago started me thinking about distributed caching options for .NET. Among the well known distributed caching products, only NCache was designed specifically for .NET, with Microsoft’s own Velocity project expected to mature into a viable product shortly. Others such as Oracle Coherence, Terracotta with EHCache , VMWare GemFire and GigaSpaces XAP are based on non-.NET (primarily Java) ecosystems, but most of them provide some level of support for .NET applications. This post provides a simple framework for comparing the .NET support provided by these products and a summary of what I found when I began exploring GigaSpaces’ XAP .NET edition.

Framework for Comparison

.NET support can be divided into a three tiered hierarchy:

Tier One – It must be possible for a .NET client program to store .NET objects to the cache, retrieve them from the cache, and operate on them. This is the sine qua non of .NET support in a caching product.

Tier Two – For caching products that allow the user (developer) to implement server-side processing that is closely integrated with the cache, the second tier of .NET support lets the developer implement the server-side logic in a .NET language.

Tier Three – A caching product could be implemented entirely in a .NET language and be fully harmonized with the broader .NET ecosystem. As we have already observed, none of the best known products are built this way.

An orthogonal consideration – supported languages – can be applied to all three tiers. Compatibility with one .NET language doesn’t imply compatibility with all .NET languages; cross-language interoperability depends on compliance with Microsoft’s Common Language Specification (CLS) http://msdn.microsoft.com/en-us/library/730f1wy3(v=vs.71).aspx. So, although C# is likely to be the language of interest for most organizations that are looking for a .NET-compatible distributed caching solution, it is worth noting whether or not the .NET support provided in these products extends to other .NET languages as well.

GigaSpaces XAP .NET

First, a refresher on XAP: This GigaSpaces product began as a distributed caching framework designed to reduce latency when accessing application data, be highly scalable, and simplify the construction of “real-time” (event-driven) systems. Unlike most caches which are based on the key – value paradigm, GigaSpaces is based on Java spaces, which is an implementation of tuple spaces http://en.wikipedia.org/wiki/Tuple_space. Tuples provide more generalized data matching features than do key – value pairs, and tuple spaces feature strong, built-in concurrency controls.

As new capabilities were added, the XAP framework evolved from a caching system to a full-featured application development and management platform. In addition to highly available caching, XAP now provides several server-side processing options, event notification and distribution, an SLA-based managed execution environment, dynamic scalability, multi-site replication and – of course – .NET support.

In the terminology of the framework described in the previous section, XAP .NET provides tiers one and two functionality, with support for C# and Visual Basic (VB .NET).

Tier One Support

XAP .NET includes a C# API for use when writing a caching client. The API provides classes and methods for creating or connecting to a cache, writing data to the cache, reading data from the cache, and querying or searching the cache for objects that match specific criteria. Transactional and concurrency control features are also available for use when needed.

Tier Two Support

Server side application logic can be implemented for execution on demand or in response to data events or conditions with GigaSpaces .NET. On-demand logic takes the form of remote procedure calls. Processing logic is implemented in C#, as is the interface contract. Clients use features of the C# API to invoke the remote procedures.

Event driven logic can be implemented as either a polling mechanism or an event notification mechanism. The polling conditions or event registration (depending on which mechanism is in use) are specified in C#, as is handler code that receives the result of the polling operation or is notified of the data event.

Note that the client program that triggers the server-side event need not be a .NET program.

Four Coherence-based Solutions to a Data Hot Spot Problem

subuta — Wed, 31 Aug 2011 18:25:57 +0000

Summary

Leveraging the DICE framework I developed last year (write-up available under “Papers and Articles” at http://www.scapps.co.uk), I developed four different solutions to a simplified (non-distributed) variant of the DICE computing problem using Coherence 3.7, each using a different approach to concurrency management. I then measured the throughput of each implementation using DICE configurations that promote a high rate of concurrent requests for access to shared data objects.

The implementation based on Coherence’s Entry Processors feature showed the highest throughput.

Two of the four implementations provide ACID transactional guarantees. The transactional implementations provided lower throughput than the non-transactional implementations.

One of the two transactional implementations uses a Coherence transactionality feature which is now deprecated. The other uses Coherence’s new Transactions Framework. The transactional implementation based on the deprecated Coherence feature provided greater throughput than the implementation based on the new Transaction Framework.

Simplified DICE Computing Problem

There are two domain classes:

Counters, each with a unique identifier and a counter value.
Incrementers, each containing a unique identifier and a reference to a Counter, and a flag that is used to distinguish between Incrementers that have and have not been processed. Each Incrementer represents an event to be processed.

Processing an Incrementer event involves the following steps:

The Incrementer object is interrogated to obtain the id of the Counter object to which it refers.
The Counter object is located.
The value of the Counter object’s counter field is incremented.
The Incrementer object’s processed flag is set.
The new state of the Counter is saved in the shared data area.
The Incrementer is written to the shared data area. The throughput being measured is the rate at which these update operations (DICE ops.) are performed.

This problem is a simplified version of the original DICE problem, which required that domain data and processing be distributed across more than one host. In the simplified version presented here, all data is stored and all processing is done on a single host. Note, however, that the solutions presented here can also work without modification with distributed clients, data or both.

The Four Implementations

The client program in each of the four implementations is a cluster member without local storage. The cache(s) needed by each implementation are established and managed by another cluster member which is started before the client is run.

The four implementations differ in the ways they perform DICE ops:

Client non-transactional – The client’s worker threads read from and write to the caches, using explicit locks to manage concurrency. Two caches are used, one per domain type.
EntryProcessor non-transactional – The client’s worker threads send Entry Processors to the cluster member that hosts the data. That cluster member performs the updates, taking advantage of the Entry Processors’ inherent concurrency controls. One cache is used for both domain types so that a single Entry Processor can be used for each DICE op.
Client transactional deprecated – The client’s worker threads read from and write to the caches using the (deprecated) TransactionMap interface. Pessimistic mode is used to manage concurrency. Two caches are used, one per domain type.
Client transactional Transaction Framework – The client’s worker threads read from and writes to the caches using the Transaction Framework’s OptimisticNamedCache interface. When updates fail for concurrency-related reasons (either a required lock is unavailable or the optimistic assumption proves false), retries are issued automatically. Two caches are used, one per domain type.

Each DICE Op. Includes two writes to the cache: a Counter is updated, and an Incrementer is inserted. In the two transactional implementations, these writes are performed as an atomic operation. In the non-transactional implementation they are not.

DICE Configuration

Here are some key points from the DICE application configuration used for these tests:

The number of Counter objects was set to two for one series of tests, and to ten for another series (as shown in the table of results).
One client instance was run for each test execution.
The client spawned five worker threads that initiated DICE ops.
Each thread was instructed to execute 2,000 DICE ops.
(The total number of DICE ops. per test was therefore 5 x 2,000 = 10,000.)
Counter objects each contain a string field that can be populated to increase the size of each instance. For these tests a string of 4,096 bytes was used.

Coherence Cache Configuration

Here are some key points from the Coherence cache configuration used for these tests:

A distributed scheme managed by the DistributedCache service was used for the two non-transactional implementations and the transactional implementation based on the deprecated TransactionMap interface.

A transactional scheme managed by the TransactionalCache service was used for the TransactionMap implementation.
In both cases, thread-count was set to two; lease-granularity was set to ‘lease’; and an unlimited backing map local scheme was used.

Observed Throughput

The Coherence license under which I am working does not allow me to “disclose results of any program benchmark tests without our prior consent”. Because I don’t have Oracle’s consent to publish my observations, I am reporting results on a relative basis, with the throughput rates I observed indexed to the lowest value.

Several iterations of the test were run with each implementation. The table that follows shows the best throughput achieved by each implementation with two and five Counters respectively, indexed to the throughput of the lowest observed rate (Transaction Framework with two Counters).

implementation	no. Counters	indexed throughput
EntryProcessor non-transactional	2	11.7
client non-transactional	2	3.7
client transactional deprecated	2	2.4
client transactional Transaction Framework	2	1.0
EntryProcessor non-transactional	10	12.1
client non-transactional	10	5.3
client transactional deprecated	10	3.1
client transactional Transaction Framework	10	2.1

When considering these results it is important to remember that:

Throughput was measured using a DICE configuration designed to produce very heavy contention for access to a small number of data elements.
Neither the execution environment nor the Coherence configuration were tuned to optimize the throughput of any of the implementations.

Conclusions and Interpretation

Higher rates of throughput were achieved by the non-transactional implementations than by the transactional implementations. Presumably this is because of the overhead required to support the atomicity and isolation properties of transactions.

Of the two non-transactional implementations, the implementation that used EntryProcessors provided greater throughput by a factor of more than two. This advantage is likely attributable to the smaller amount of inter-process communication required by the Entry Processors compared with the non-transactional client implementation.

Of the two transactional implementations, the one based on the deprecated TransactionMap feature showed greater throughput. This is probably because its pessimistic mode is more efficient than the Transaction Framework’s optimistic concurrency control for this use-case, which is write-intensive and contention-intensive by design.

As shown in the following table, each implementation achieved greater throughput when the number of Counters was increased (although in the case of the EntryProcessor implementation the increase was only about 4%). The reduced rate of contention for each Counter probably explains the increases.

implementation	% change
EntryProcessor non-transactional	4%
client non-transactional	42%
client transactional deprecated	33%
client transactional Transaction Framework	134%

The percentage improvement in throughput when the number of counters was increased was greatest (134%) for the Transaction Framework implementation. The likely explanation is that the cost of the retries used by this implementation to recover from concurrency conflicts is very high. With the updates spread across five times as many Counters the number of retries was substantially reduced.

As the following table show, the throughput advantage of the implementation using the deprecated TransactionMap feature over the implementation using the newer Transaction Framework became much smaller percentage-wise when the number of Counters was increased from two to ten. This observation suggests that the retries employed by the Transaction Framework implementation to resolve concurrency conflicts account for most of the difference in throughput rates between the old and new transactionality features.

Counters	% increase
Two Counters	136%
Ten Counters	34%

Lightning Talk at CloudCamp

subuta — Sun, 30 Aug 2009 12:21:24 +0000

Last month I gave a five minute talk about GigaSpaces and Terracotta at London’s CloudCamp, an event which was well organized, well attended and well received. If you care to see my talk, follow this link:

http://skillsmatter.com/podcast/cloud-grid/refreshment-break-select-breakout-session

(videos generously hosted by the folks at Skills Matter). Click around and you’ll find a lot more good content.

A Simple Illustration of Terracotta Locking Strategies

subuta — Sun, 28 Jun 2009 18:09:57 +0000

If you are familiar with Terracotta then you know that its hallmark feature is data sharing between Java programs running on different virtual machines. Making use of this very powerful capability requires that the the programs that share the data use Java synchronization to prevent conflicts between operations that access the shared data from corrupting the data or returning incomplete results. Terracotta data sharing also requires that Terracotta be configured to detect and honour the Java synchronization instructions. In this post we refer to the combination of Java synchronization and Terracotta configuration as a “locking strategy”.

The choice of locking strategy can have a profound impact on a Terracotta application’s performance. Even in a very simple application, there may be several points of data contention at which locking strategies are required, and several possible locking strategies for each contention point. This post provides a very brief illustration of how locking strategies are implemented with Terracotta, and of the impact that a small change in locking strategy can have on application performance.

This post barely scratches the surface of Terracotta’s remarkable data sharing capabilities, and it completely bypasses many other powerful and important features of the product. Readers are advised to regard this post as a very simple illustration of some basic principles of working with Terracotta, and nothing more.

Readers should also understand that this post demonstrates use of Terracotta’s low level concurrency features. Many Terracotta users will find themselves using Terracotta’s integration modules (TIMS), which provide out-of-the-box integration with productivity frameworks such as Hibernate and Spring. The intent of the developers of these integration modules seems to be to shield users of the module as much as possible from the kinds of low level concurrency concerns that feature prominently in this post.

As a starting point, we create two Java programs from three classes:
A – a data POJO.
TCLockingExampleMain – a program that creates and instance of A and updates A’s data field.
TCLockingExampleReporter – a program that indicates whether or not our data is shareable.

Here is the source code for all three classes prior to implementing any locking strategy:

package tcLockingExample;

public class A {
int primInt;

public void primIntInc() {
this.primInt++;
}
}

package tcTLockingExample;

public class TCLockingExampleMain {
static A aInstance = new A();

/**
* @param args
*/
public static void main(String[] args) {
for (int x = 0; x < 10; x++ ) {
aInstance.primIntInc();
System.out.println(“aInstance.primInt: ” + aInstance.primInt);
}
}
}

package tcTLockingExample;

import java.util.Date;

public class TCLockingExampleReporter {

/**
* @param args
*/
public static void main(String[] args) {
System.out.println(new Date() + ” TCLockingChoicesMain.aInstance.primInt:” + TCLockingExampleMain.aInstance.primInt);
}
}

We will be tinkering with the first two classes as the example progresses.

The first step is to establish that the programs work as expected when run without Terracotta. As the following output illustrates, both programs run:

aInstance.primInt: 1
aInstance.primInt: 2
aInstance.primInt: 3
aInstance.primInt: 4
aInstance.primInt: 5
aInstance.primInt: 6
aInstance.primInt: 7
aInstance.primInt: 8
aInstance.primInt: 9
aInstance.primInt: 1

but, of course, there is no data sharing between them:

Sun Jun 07 17:48:16 BST 2009 TCLockingChoicesMain.aInstance.primInt:0

Next we run each prgram as a Terracotta application, but without configuring Terracotta to share data between them. The results are the same:

2009-06-07 18:06:48,029 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:06:48,334 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:06:48,494 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:06:49,907 INFO – Connection successfully established to server at 192.168.1.20:9510
aInstance.primInt: 1
aInstance.primInt: 2
aInstance.primInt: 3
aInstance.primInt: 4
aInstance.primInt: 5
aInstance.primInt: 6
aInstance.primInt: 7
aInstance.primInt: 8
aInstance.primInt: 9
aInstance.primInt: 10

and from TCLockingExampleReporter:

2009-06-07 18:09:03,467 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:09:03,772 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:09:03,905 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:09:05,199 INFO – Connection successfully established to server at 192.168.1.20:9510
Sun Jun 07 18:09:05 BST 2009 TCLockingChoicesMain.aInstance.primInt:0

Next we configure Terracotta to be aware of all three classes, and set a trap for ourselves by establishing the instance of A in TCLockingExampleMain as a root class (a Terracotta root is an object that is identified as shared by the application’s Terracotta configuration):

tcTLockingExample.A

tcTLockingExample.TCLockingExampleMain

tcTLockingExample.TCLockingExampleReporter

tcTLockingExample.TCLockingExampleMain.aInstance

This is a trap because, having established TCLockingExampleMain.aInstance as a shared object, we are obliged to implement a locking strategy wherever we write to it in our code. Because we have not done this, TCLockingExampleMain fails:

2009-06-07 18:13:48,927 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:13:49,240 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:13:49,371 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:13:50,845 INFO – Connection successfully established to server at 192.168.1.20:9510
com.tc.object.tx.UnlockedSharedObjectException:
*********************************************************************
Attempt to access a shared object outside the scope of a shared lock.
All access to shared objects must be within the scope of one or more
shared locks defined in your Terracotta configuration.

Caused by Thread: main in VM(0)
Shared Object Type: tcTLockingExample.A

The cause may be one or more of the following:
* Terracotta locking was not configured for the shared code.
* The code itself does not have synchronization that Terracotta
can use as a boundary.
* The class doing the locking must be included for instrumentation.
* The object was first locked, then shared.

For more information on how to solve this issue, see:

http://www.terracotta.org/usoe

*********************************************************************

at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:360)
at com.tc.object.tx.ClientTransactionManagerImpl.fieldChanged(ClientTransactionManagerImpl.java:653)
at com.tc.object.TCObjectImpl.objectFieldChanged(TCObjectImpl.java:317)
at com.tc.object.TCObjectImpl.intFieldChanged(TCObjectImpl.java:357)
at tcTLockingExample.A.__tc_setprimInt(A.java)
at tcTLockingExample.A.primIntInc(A.java:7)
at tcTLockingExample.TCLockingExampleMain.main(TCLockingExampleMain.java:11)
Exception in thread “main” com.tc.object.tx.UnlockedSharedObjectException:
*********************************************************************
Attempt to access a shared object outside the scope of a shared lock.
All access to shared objects must be within the scope of one or more
shared locks defined in your Terracotta configuration.

Caused by Thread: main in VM(0)
Shared Object Type: tcTLockingExample.A

The cause may be one or more of the following: . . .

To fix this we will implement our first locking strategy, by synchronizing the method in A that writes to the data member of the shared instance:
package tcLockingExample;

public class A {
int primInt;

synchronized public void primIntInc() {
this.primInt++;
}
}

and configuring Terracotta to apply its locking to that method:

tcLockingExample.A

tcLockingExample.TCLockingExampleMain

tcLockingExample.TCLockingExampleReporter

tcLockingExample.TCLockingExampleMain.aInstance

void tcLockingExample.A.primIntInc()
write

Now TCLockingExampleMain works:

2009-06-07 18:24:22,965 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:24:23,284 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:24:23,414 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:24:25,324 INFO – Connection successfully established to server at 192.168.1.20:9510
aInstance.primInt: 1
aInstance.primInt: 2
aInstance.primInt: 3
aInstance.primInt: 4
aInstance.primInt: 5
aInstance.primInt: 6
aInstance.primInt: 7
aInstance.primInt: 8
aInstance.primInt: 9
aInstance.primInt: 10

and TCLockingExampleReporter shows that the data is being shared:

2009-06-07 18:27:21,486 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:27:21,804 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:27:21,933 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:27:23,271 INFO – Connection successfully established to server at 192.168.1.20:9510
Sun Jun 07 18:27:23 BST 2009 TCLockingChoicesMain.aInstance.primInt:10

Next we try a different locking strategy. We remove the synchronization from A’s method, and instead synchronize TCLockingExampleMain’s write operation on the root object:

package tcLockingExample;

public class TCLockingExampleMain {
static A aInstance = new A();

/**
* @param args
*/
public static void main(String[] args) {
for (int x = 0; x < 10; x++ ) {
synchronized(aInstance) {
aInstance.primIntInc();
}
System.out.println(“aInstance.primInt: ” + aInstance.primInt);
}
}
}

We also update the Terracotta configuration, applying a Terracotta autolock (which means that Terracotta will add its locking wherever it sees Java synchronization) to TCLockingExampleMain’s main() method instead of A’s incrementer method:

tcLockingExample.A

tcLockingExample.TCLockingExampleMain

tcLockingExample.TCLockingExampleMain.aInstance

void tcLockingExample.TCLockingExampleMain.main(java.lang.String[])
write

This strategy also works:
2009-06-07 18:45:39,099 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:45:39,425 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:45:39,555 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:45:41,441 INFO – Connection successfully established to server at 192.168.1.20:9510
aInstance.primInt: 1
aInstance.primInt: 2
aInstance.primInt: 3
aInstance.primInt: 4
aInstance.primInt: 5
aInstance.primInt: 6
aInstance.primInt: 7
aInstance.primInt: 8
aInstance.primInt: 9
aInstance.primInt: 10

and data sharing is enabled:
2009-06-07 18:44:17,498 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 18:44:17,816 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 18:44:17,951 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 18:44:19,710 INFO – Connection successfully established to server at 192.168.1.20:9510
Sun Jun 07 18:44:19 BST 2009 TCLockingChoicesMain.aInstance.primInt:10

Finally we’ll take a quick look at how the choice of locking strategy can affect performance. To see this, we change TCLockingExampleMain so it increments A’s integer member a million times instead of ten as in previous executions. We also add some code to tell us how long the program took to do the million iterations:

package tcLockingExample;

import java.util.Date;

public class TCLockingExampleMain {
static A aInstance = new A();

/**
* @param args
*/
public static void main(String[] args) {
Date startTime = new Date();
for (int x = 0; x < 1000000; x++) {
aInstance.primIntInc();
}
Date endTime = new Date();
System.out.println(“startTime: ” + startTime + ” endTime: ” + endTime
+ ” elapsed: ”
+ ((endTime.getTime() – startTime.getTime()) / 1000)
+ ” seconds”);
System.out.println(“aInstance.primInt: ” + aInstance.primInt);
}
}

When we run this program we see that the million iterations take around 26 seconds:

2009-06-07 19:16:09,091 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 19:16:09,410 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 19:16:09,544 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 19:16:11,022 INFO – Connection successfully established to server at 192.168.1.20:9510
startTime: Sun Jun 07 19:16:11 BST 2009 endTime: Sun Jun 07 19:16:37 BST 2009 elapsed: 26 seconds
aInstance.primInt: 1000000

Next we try our second locking strategy with a million iterations:

package tcLockingExample;

import java.util.Date;

public class TCLockingExampleMain {
static A aInstance = new A();

/**
* @param args
*/
public static void main(String[] args) {
Date startTime = new Date();
for (int x = 0; x < 1000000; x++) {
synchronized (aInstance) {
aInstance.primIntInc();
}
}
Date endTime = new Date();
System.out.println(“startTime: ” + startTime + ” endTime: ” + endTime
+ ” elapsed: ”
+ ((endTime.getTime() – startTime.getTime()) / 1000)
+ ” seconds”);
System.out.println(“aInstance.primInt: ” + aInstance.primInt);
}
}

It takes about the same amount of time:

2009-06-07 19:21:08,279 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 19:21:08,602 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 19:21:08,737 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 19:21:10,266 INFO – Connection successfully established to server at 192.168.1.20:9510
startTime: Sun Jun 07 19:21:10 BST 2009 endTime: Sun Jun 07 19:21:37 BST 2009 elapsed: 26 seconds
aInstance.primInt: 1000000

For our last test we move the synchronization statement outside of the loop, meaning that only one lock is required instead of a million (one per iteration):

package tcLockingExample;

import java.util.Date;

public class TCLockingExampleMain {
static A aInstance = new A();

/**
* @param args
*/
public static void main(String[] args) {
Date startTime = new Date();
synchronized (aInstance) {
for (int x = 0; x < 1000000; x++) {
aInstance.primIntInc();
}
}
Date endTime = new Date();
System.out.println(“startTime: ” + startTime + ” endTime: ” + endTime
+ ” elapsed: ”
+ ((endTime.getTime() – startTime.getTime()) / 1000)
+ ” seconds”);
System.out.println(“aInstance.primInt: ” + aInstance.primInt);
}
}

Execution time drops from 26 seconds to less than one second:

2009-06-07 19:23:52,409 INFO – Terracotta 3.0.0, as of 20090410-200435 (Revision 12431 by cruise@su10mo5 from 3.0)
2009-06-07 19:23:52,727 INFO – Configuration loaded from the file at ‘/home/dan/workspace/TCLockingExample/tc-config.xml’.
2009-06-07 19:23:52,861 INFO – Log file: ‘/home/dan/workspace/TCLockingExample/terracotta/client-logs/terracotta-client.log’.
2009-06-07 19:23:54,335 INFO – Connection successfully established to server at 192.168.1.20:9510
startTime: Sun Jun 07 19:23:54 BST 2009 endTime: Sun Jun 07 19:23:55 BST 2009 elapsed: 0 seconds
aInstance.primInt: 1000000

As these very simple examples show, there are often several choices for how to implement locking in a Terracotta application, and the selection of a strategy can have profound implications for application performance. For a developer who is new to Terracotta, selecting appropriate locking strategies may involve significant amounts of trial and error. As the developer’s understanding of Terracotta grows with experience, locking strategy selection becomes easier and less experimentation is required.

Exercising Terracotta’s Virtual Heap

subuta — Mon, 01 Jun 2009 20:03:36 +0000

Chapter 4 of The Definitive Guide to Terracotta says:

When you traverse a reference to a clustered object that isn’t currently instantiated on the local physical heap, Terracotta will automatically request that object’s data from the Terracotta server, instantiate it on the local heap, and wire up the reference you are traversing, and your application will be none the wiser.

Likewise, Terracotta can artificially add null references to clustered objects as memory pressure increases, which lets arbitrarily large clustered object graphs fit within a constrained physical heap space.

I ran a couple of experiments to help me understand how these capabilities translate into application behaviour. You can download the source code for the simple Java programs I used in these experiments here.

The first question I wanted to answer was whether or not Terracotta’s ability to page heap objects in and out would allow a Terracotta client to create an object graph that was too big for its physical heap. The book states that a program can traverse an object graph that is too large for its heap, but it does not claim that the virtualization effect applies to object creation. Nevertheless I thought the possibility was worth investigating.

I designed the experiment to test this as follows:

Determine how many instances of a class of a fixed size (just over 3 kB) can be created and added to a HashMap by a non-Terracotta Java application running with a heap space of a known size before the application runs out of heap space.
Determine how many instances of the same fixed size class can be created by the same Java application running as a Terracotta client application with the HashMap holding the object instances configured as a Terracotta root, and with a heap space of the same known size.

I foresaw two possible outcomes:

The numbers of objects created by the two programs would be about the same, indicating that Terracotta’s ability to relieve memory pressure does not apply to pressure caused by the creation of new objects.
The Terracotta client would be able to create many more instances of the test object than its plain Java counterpart did, indicating that Terracotta’s object paging feature detects and handles memory pressure caused by the creation of new objects.

The actual results matched the second of the scenarios I had envisioned. When I ran the test with a heap size of 100 megabytes, the plain Java client created 2,988 instances of the test object before running out of memory.

dan@scapps1:~/workspace/bigHeap$ java -Xms100m -Xmx100m -classpath ./bin bigHeap.BigHeapMain 2988

Done so far: 1000 total memory: 100532224 free memory: 68213168

Done so far: 2000 total memory: 100532224 free memory: 36038896

dan@scapps1:~/workspace/bigHeap$

Running as a Terracotta client, the program successfully instantiated more than 11,000 instances running with a server provisioned with 512 megabytes of heap:

dan@scapps1:~/workspace/bigHeap$ dso-java.sh -Xms100m -Xmx100m -classpath ./bin bigHeap.BigHeapMain 11010

Starting BootJarTool…

2009-06-01 00:08:30,423 INFO – Terracotta 3.0.0, as of 20090409-180411 (Revision 12431 by cruise@su10mo5 from 3.0)

2009-06-01 00:08:30,748 INFO – Configuration loaded from the file at ‘/home/dan/workspace/bigHeap/tc-config.xml’.

Starting Terracotta client…

2009-06-01 00:08:32,353 INFO – Terracotta 3.0.0, as of 20090409-180411 (Revision 12431 by cruise@su10mo5 from 3.0)

2009-06-01 00:08:32,673 INFO – Configuration loaded from the file at ‘/home/dan/workspace/bigHeap/tc-config.xml’.

2009-06-01 00:08:32,804 INFO – Log file: ‘/home/dan/workspace/bigHeap/terracotta/client-logs/terracotta-client.log’.

2009-06-01 00:08:34,786 INFO – Connection successfully established to server at 192.168.1.20:9510

Done so far: 1000 total memory: 93257728 free memory: 39313736

Done so far: 2000 total memory: 93257728 free memory: 34530984

Done so far: 3000 total memory: 93257728 free memory: 33617040

Done so far: 4000 total memory: 93323264 free memory: 36051464

Done so far: 5000 total memory: 93257728 free memory: 24922912

Done so far: 6000 total memory: 93061120 free memory: 10904496

Done so far: 7000 total memory: 93257728 free memory: 39410008

Done so far: 8000 total memory: 93257728 free memory: 32656648

Done so far: 9000 total memory: 93585408 free memory: 28937584

Done so far: 10000 total memory: 93257728 free memory: 23353536

Done so far: 11000 total memory: 93257728 free memory: 29487976

dan@scapps1:~/workspace/bigHeap$

My second experiment was designed to confirm the book’s claim that a client program can operate on an object graph that is too big for the client’s heap. To test this I used a program that iterates over all of the objects in the HashMap created by the program I used for the first experiment. With a 19 megabyte heap the program successfully reads all of the objects in the HashMap, the actual size of which is on the order of 33 megabytes:

dan@scapps1:~/workspace/bigHeap$ dso-java.sh -Xms19m -Xmx19m -classpath ./bin bigHeap.CountEm

Starting BootJarTool…

2009-06-01 00:22:37,684 INFO – Terracotta 3.0.0, as of 20090409-180411 (Revision 12431 by cruise@su10mo5 from 3.0)

2009-06-01 00:22:38,010 INFO – Configuration loaded from the file at ‘/home/dan/workspace/bigHeap/tc-config.xml’.

Starting Terracotta client…

2009-06-01 00:22:39,880 INFO – Terracotta 3.0.0, as of 20090409-180411 (Revision 12431 by cruise@su10mo5 from 3.0)

2009-06-01 00:22:40,204 INFO – Configuration loaded from the file at ‘/home/dan/workspace/bigHeap/tc-config.xml’.

2009-06-01 00:22:40,334 INFO – Log file: ‘/home/dan/workspace/bigHeap/terracotta/client-logs/terracotta-client.log’.

2009-06-01 00:22:42,349 INFO – Connection successfully established to server at 192.168.1.20:9510

Found: 11010

dan@scapps1:~/workspace/bigHeap$

These simple experiments demonstrate that Terracotta’s virtual heap can be used to allow client programs to manage datasets that are too large for their physical heaps. The virtual heap is just one of Terracotta’s distinctive and powerful features. I’ll examine others in subsequent posts.

An Even Briefer Look at Distributed Transactions in GigaSpaces

subuta — Mon, 25 May 2009 07:39:57 +0000

A couple of weeks ago I posted a quick example and explanation of a GigaSpaces local transaction. You can find the post here and get the code here.

In today’s short post I will extend that example to use a distributed transaction. We’ll do this in two steps: first we’ll break the example; then we’ll fix it.

As a reminder, a GigaSpaces distributed transaction is any transaction that operates on more than one primary space. In the example code, our client program executed a local transaction when it wrote two instances of TestClass to a single instance remote space.

In that example routing was not a concern because we created the space as unpartitioned, and we did not declare a space routing field. Behind the scenes, however, GigaSpaces selected one (the id field) for us. You can check this on the Space Browser tab by expanding the GSSimpleTranExample space node, clicking on “Classes”, then clicking on “TestClass”. The name of Routing Filed will appear on the Classes Info tab just above the table showing the fields (only one in our case) in the class.

Now drop the space using Undeploy Application on the Cluster Runtime tab. Then recreate it as a partitioned space with two partitions and no backups. Rerun the client application, and it will fail with this error message:

Exception in thread “main” org.openspaces.core.TransactionDataAccessException: Invalid operation – local transaction spans over multiple spaces – [GSSimpleTranExample_container2:GSSimpleTranExample, GSSimpleTranExample_container1:GSSimpleTranExample] !
You might be using hash based load balancing (partitioned schema) while writing data into multiple spaces and not into a single node.
Please Use Jini Transaction manager with your operations.
; nested exception is net.jini.core.transaction.TransactionException: Invalid operation – local transaction spans over multiple spaces – [GSSimpleTranExample_container2:GSSimpleTranExample, GSSimpleTranExample_container1:GSSimpleTranExample] !
You might be using hash based load balancing (partitioned schema) while writing data into multiple spaces and not into a single node.
Please Use Jini Transaction manager with your operations.

The reason is that GigaSpaces attempted to route each of the two writes to different partitions, which turned our local transaction into a distributed transaction. Because we configured the application with a local transaction manager, the transaction fails.

To fix the application we need to specify a distributed transaction manager instead of a local one. Here’s how:

Find the line in the Spring application context file, GSSimpleTranExample.xml, in which we specify a transaction manager:

<os-core:local-tx-manager id=“transactionManager” space=“gSSimpleTranExample”/>

and replace it with a line that looks like this:

<os-core:distributed-tx-manager id=“transactionManager” />

Note that the distributed transaction manager, unlike a local transaction manager, is not associated with a particular space.

Now run the client application. This time it should work. You can confirm the transactional behaviour using the techniques described in the earlier post.

DICE Paper Ready at Long Last

subuta — Thu, 21 May 2009 09:00:47 +0000

I’ve mentioned my DICE study – a comparison of eight different solutions to a simple distributed computing problem using GigaSpaces and Terracotta – in several posts. It is finally available for download. If you want to take a look, please follow the link to the scapps website. Access to the paper is quick and easy.

A Brief Look at Local Transactions in GigaSpaces

subuta — Tue, 12 May 2009 07:00:27 +0000

Introduction

One way to think about GigaSpaces¹ is as a sort of database management system for maintaining and accessing data spread across a set of caches. Of course this view ignores many important capabilities of the GigaSpaces framework, but it is a useful perspective for considering GigaSpaces’ transactional features.

GigaSpaces offers transactional control over access to data in its spaces. When the right combinations of API features are employed, data operations assume ACID characteristics.

As a reminder, ACID is an acronym standing for “atomic, consistent, isolated and durable”. The term refers to the behaviour that is generally expected from transactional systems. Quoting Wikipedia:

Atomicity: Either all the tasks in a transaction must be done, or none of them. The transaction must be completed, or else it must be undone (rolled back).
Consistency: Every transaction must preserve the integrity constraints — the declared consistency rules — of the database. It cannot place the data in a contradictory state.
Isolation: Two simultaneous transactions cannot interfere with one another. Intermediate results within a transaction are not visible to other transactions.
Durability: Completed transactions cannot be aborted later or their results discarded. They must persist through (for instance) restarts of the DBMS after crashes

It is important to understand that GigaSpaces transactions govern only the state of data in the spaces managed by GigaSpaces. Unlike the transactional support provided by heap-oriented products such as Terracotta and Kabira, GigaSpaces transactions do not provide guarantees concerning access to or the state of heap memory in a GigaSpaces application.

Lineage

GigaSpaces’ transaction support derives from three sources:

1. Jini – At its core, GigaSpaces is an implementation of the JavaSpaces specification, which is a component of the Jini specification. Jini was designed to allow heterogeneous software and hardware devices to interact. The Jini specification (and reference implementation) include a facility for Jini-compliant devices to participate in distributed transactions. GigaSpaces has inherited and extended this capability.

2. JTA (Java Transaction API) – Jini provides the ability to orchestrate transactions among Jini-compliant participants such as JavaSpaces. Sometimes, however, it may be necessary to engage in a transaction both participants that are Jini-compliant and participants that do are not Jini-compliant. For example, a GigaSpaces application might need to remove a data entry from a space and insert a corresponding row into a table in an RDBMS. Most RDBMSs support a distributed transaction protocol called XA that allows them to participate in transactions with otherwise independent participants. Using JTA, GigaSpaces can participate in XA distributed transactions.

3. Spring – The Spring framework provides an abstraction of transaction management services and constructs. GigaSpaces has embraced this abstraction and uses it as the façade for its own transaction support.

To this mix GigaSpaces adds support for local transactions, meaning transactions that involve only one instance of one space.

Transaction Control

Mirroring Spring’s capabilities, GigaSpaces offers two modes of transaction control, programmatic and declarative. With programmatic transaction control, the programmer uses API calls to configure, start, commit and abort transactions. With declarative transaction control, the programmer includes directives about where and how transactional behaviour should be applied. These directives are interpreted by Spring and translated into transactional control statements that are woven into the application at runtime.

Spring declarative transaction control itself takes two forms, both of which are supported by GigaSpaces. First, it can be configured using a pointcut specification typical of aspect-oriented implementations. Second, methods can be annotated to indicate that they should (or should not) be executed within transactions.

A Simple Example

Get the source code for this example here.

Here is a simple application that illustrates how to implement a local transaction with GigaSpaces using annotation-driven declarative transaction control. The example creates two instances of a class, then writes both instances to a space within a transaction.

There are five files:

A spring application context file – GSSimpleTranExample.xml – that sets up the proxy by which the application will access the space. The transaction manager is defined here.
A simple POJO class – TestClass.java – two instances of which will be written to the space under a transaction.
A Java interface – ConnBeanInterface.java – that declares the methods that will be used to access the space. The interface – implementation pattern is used because Spring works better with instances of interfaces than with instances of concrete classes.
A Java bean – ConnBean.java – that performs the space operations.
A Java main program – GSSimpleTranExample.java – that instantiates the objects to be written to the space and invokes the method to write them.

Let’s start by looking at the Spring application context file. The first item of interest is an Spring namespace element that instructs Spring to apply transactional controls to methods that are annotated with @Transactional in beans that it is managing:

<tx:annotation-driven />

The name of a transaction manager bean can be specified as an attribute to this element. This is the bean containing the transaction manager that will be used to manage the transactional behaviour of the annotated methods that Spring finds in the beans that it manages. If none is specified, as in our example, a default value of “transactionManager” is assumed.

Next is an OpenSpaces namespace element that instruct Spring to instantiate a transaction manager:

<os-core:local-tx-manager id=“transactionManager” space=“gSSimpleTranExample”/>

In our case we are using GigaSpaces’ local transaction manager. This is the best choice when each transaction will involve only a single partition of a single space.

Notice that the transaction manager declaration contains a reference to a space. As we will see shortly, this construct is one of two that constitute an apparent redundancy in the OpenSpaces namespace support for transactions.

Next we see a typical OpenSpaces namespace space declaration that tells Spring to create a an IJSpace instance:

<os-core:space id=“gSSimpleTranExample” url=“jini://*/*/GSSimpleTranExample” />

There is nothing specifically transactional about it; it is included in this discussion because the next element, which has a transactional dimension, refers to it.

Next is an OpenSpaces declaration of a GigaSpace:

<os-core:giga-space id=“gigaSpace” space=“gSSimpleTranExample”

tx-manager=“transactionManager” />

Note that this element includes both an explicit reference to the transaction manager declared earlier, and refers to the space that was defined earlier and that also refers to the transaction manager.

<os-core:giga-space id=“gigaSpace” space=“gSSimpleTranExample”

tx-manager=“transactionManager” />

Next we specify our application bean that will perform the space operations:

Spring will instantiate this bean and manage its lifecycle.

We also include the OpenSpaces GigaSpace context element:

<os-core:giga-space-context />

so that Spring will assign the GigaSpace bean declared in the context file to a variable of type GigaSpace that is annotated with the @GigaSpaceContext annotation in our ConnBean instance.

The TestClass is not transaction-aware, and is not described further.

The ConnBeanInterface declares the method that will be implemented in ConnBean:

public interface ConnBeanInterface {

public void writeTwoObjects(TestClass tCI1, TestClass tCI2);

}

Note that, although it is not transaction-aware, it could have been, as we have the option of annotating the interface class or its methods to be transactional.

The implementation of:

public void writeTwoObjects(TestClass tCI1, TestClass tCI2) {

in our ConnBean class is transactional:

@Transactional

public void writeTwoObjects(TestClass tCI1, TestClass tCI2) {

gigaSpace.write(tCI1);

gigaSpace.write(tCI2);

}

The @Transactional annotation tells Spring to wrap transactional controls around this method.

From our main application class, here is the code that creates two instances of TestClass, then invokes the ConnBean method that will write them to the space under a transaction:

TestClass tCI1 = new TestClass(0);

TestClass tCI2 = new TestClass(1);

connBean.writeTwoObjects(tCI1, tCI2);

Running the Example

Before running this example, create an unpartitioned space called GSSimpleTranExample.

When you run the example pass the path and name of the spring application context file as a command line argument.

It it runs successfully the program will produce the following output:

Done with my work. About to exit.

Proving the Transactional Behaviour

Here are a few techniques that can be used to explore the transactional behaviour in this example:

1. Extend the duration of the transaction and inspect it in the GigaSpaces GUI Space Browser while it is in progress. You can extend the duration of the transaction by modifying the ConnBean class as follows:

int sleepLength = 10000;

@Transactional

public void writeTwoObjects(TestClass tCI1, TestClass tCI2) {

gigaSpace.write(tCI1);

gigaSpace.write(tCI2);

try {

Thread.sleep(sleepLength);

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

sleepLength is specified in milliseconds. Set it to whatever value is convenient for you. Then run the application, and look at the list of transactions. Note that the transaction type is “Local” because we declared a local transaction manager in the application context file. Also notice that two objects are locked by this transaction. These are the two objects that are being inserted.

2. Try to query the locked objects using the Space Browser and observe that they cannot be read while the transaction is in progress. To do this, start by removing any instances of TestClass from the space. Set the value of sleepLength to a long enough duration (perhaps 30 seconds) that you will have time to execute a query against the space while the transaction is in progress. Run the program. Then select the TestClass class in the space browser and execute a query. The result set will be empty.

As you are preparing to run the query you will notice that the instance count for the TestClass class is two, not zero. This is because the method that is used by the GUI to inspect the space has access to locked objects and includes them in the count value it returns. The objects themselves, however, are not visible until the transaction commits.

3. Force the transaction to roll back, and observe that the space is left empty. To force a roll-back, raise an exception in the WriteTwoObjects() method as follows:

int sleepLength = 10000;

@Transactional

public void writeTwoObjects(TestClass tCI1, TestClass tCI2) {

gigaSpace.write(tCI1);

gigaSpace.write(tCI2);

try {

Thread.sleep(sleepLength);

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

throw (new RuntimeException());

}

Again, start by removing any instances of TestClass from the space. Now when you run the application you see the transaction in progress and the TestClass instance count will go to two. At the end of the period specified by sleepLength, the transaction will abort and the instance count will revert to zero.

1GigaSpaces technology is spread across two code bases, GigaSpaces and OpenSpaces. This paper often refers to all of the technology indiscriminately as “GigaSpaces”.

Cloud Computing and Competitive Positioning

subuta — Sun, 10 May 2009 10:56:06 +0000

(Recently posted on CIO.com)

To understand the implications of cloud computing on your organization’s competitive position, it is helpful to think about the cloud proposition from two perspectives: cost and capabilities.

Recently a contributor to these pages, citing a McKinsey & Co. report, posited that external clouds do not provide cost advantages over internal data centres for organizations with scale. Let’s assume that this is true. We can infer, at least as a hypothetically, that external clouds do provide cost advantages for smaller organizations over the in-house alternative. So, on a relative basis, a small organization that successfully exploits the potential cost savings offered by external clouds will improve its competitive position versus a competitor that is already exploiting its scale effectively and to which external clouds can provide no incremental cost advantage. The implication for CIOs at sub-scale operations is that they should examine the business case for migrating to external clouds as a means of improving their organizations’ competitive positions.

For their counterparts at larger organizations, the potential for eroding advantage means that they need to find ways to preserve or extend the cost advantages that their scale provides. Two possible approaches, not mutually exclusive, present themselves. One is to challenge their hardware and infrastructure software vendors to adjust their pricing so that large customer organizations can defend their current cost advantages against the threat posed by the new, alternative business model which seems to favour smaller organizations on a relative basis. The other is to bring cloud managements technologies and techniques into their own data centres, seeking to identify and exploit whatever inherent efficiency advantages cloud providers may enjoy without paying those providers the profit margins on which their businesses operate. Presumably any IT organization with substantial scale is already well down this path, at least with regard to host virtualization.

The sliding relationship between internal and external infrastructure costs as a function of scale is likely to have a slight but measurable impact on the relative competitive positions of smaller and larger IT organizations. The potential impact of changes in relative capabilities between cloud adopters and no-adopters is much more significant.

From an application perspective, a cloud (internal or external) is the ideal setting for horizontally scaling applications. The ability to deploy incremental processing power on demand and at low incremental cost is the perfect compliment to scalable application architectures. External clouds offer small or start-up organizations the ability to deploy applications with much greater actual or potential capacity than they could otherwise afford. Small or start-up organizations that perceive and capitalize on this potential can quickly improve their relative positioning with regard to competitors.

The ability of a newer or smaller player to punch well above its weight in terms of application capacity can neutralize a traditional advantage of scale players, transforming start-ups or small competitors into significant adversaries. Of course, exploiting this potential advantage requires that these smaller organizations adopt newer application architectures that are designed for horizontal scalability, something that larger and better established competitors may be less inclined to do. For newer, smaller or more agile players, adopting scalable application architectures may be both easier (because they are less prone to organizational inertia) and more of a strategic necessity. The risk to better established and more complacent organizations is that these upstart competitors will not only challenge the larger organizations’ competitive positions in the short term through clever use of complimentary application and infrastructure strategies, but that they will also develop a more enduing strategic advantage through there embrace of newer application paradigms.

Digesting and understanding the possible implications of the emergence of external cloud services on competitive position is difficult due to the newness of these services and fog of hype that envelops the topic of cloud computing. Clues are beginning to emerge, however, as to how this new way of acquiring and managing technical infrastructure may impact organizations differently depending on size, competitive position, and rates of adoption of newer application architectures. Thinking through these issues and developing a view on their potential competitive impact is a worthwhile exercise for any IT executive.