When One ColdFusion Is Not Enough

Jul. 11, 2003 12:00 AM

By now, every ColdFusion developer knows, or should know, that ColdFusion MX sits on top of underlying Java architecture. Some ColdFusion developers have even been brave enough to attempt ColdFusion/Java integration, creating applications that leverage Java code where appropriate. But most developers are failing to take advantage of what is undoubtedly the most significant benefit of ColdFusion on top of J2EE, a benefit so important that for some organizations it has become the only reason needed to upgrade.

Understanding the Problem
Have you ever run into any of these situations?

Your ColdFusion application is running perfectly. That is, until someone else (no, not you) writes really poor code that kills performance or worse, hurts all the applications including yours in the process.

You have several applications on your server, and want to apply a product update to some of them (the ones you have tested against) but not others.

You host applications for multiple departments or clients on the same server, but can't give developers access to the ColdFusion Administrator for fear that they'll tamper with each other's settings.

Or for that matter, you want to have different ColdFusion Administrator settings for different applications (trusted cache, custom tag paths, site-wide error handlers, and more).

You don't have multiple physical servers, but still want to provide failover in case your application goes down.

The common problem in all of these situations is that there is one shared copy of ColdFusion on any given server. All settings are shared, all paths are shared, all data sources are shared, all updates are shared, and even all bad code (or the results thereof) is shared.

There is really only one solution to this problem. Each application needs to have its own ColdFusion. That way applications won't interfere with each other. It's as simple as that. Of course, that requires buying lots of servers and lots of copies of ColdFusion, right? Wrong. Read on.

Is There a Single Server Solution?
At DevCon 2001 in Orlando, I publicly demonstrated the following:

I wrote CFML code that would throw ColdFusion into an endless loop (no easy task mind you).

I ran that code and showed that ColdFusion was no longer responding to requests properly.

I then opened another browser window and requested a ColdFusion page from the same server, and it loaded perfectly (even though the first page was still stuck and not responding).

The trick? There wasn't one. What I demonstrated was all real, no smoke and mirrors. The reason it worked is that I had more than one copy of ColdFusion installed on my computer, it's as simple as that.

Well, maybe not so simple. It did take us longer to deliver this functionality than we had originally planned, but with ColdFusion MX for J2EE we have indeed delivered the ability to run multiple instances of ColdFusion on a single server.

Understanding Multiple Instances
J2EE servers are application servers, they serve applications, and usually lots of them. In a J2EE world, applications are deployed onto a J2EE server, and each Java application lives in a safe and isolated environment. Each Java application is treated as if it were running on its own server - applications can be stopped, started, upgraded, tweaked, and managed entirely independent of any other Java application. In fact, the same Java application may be deployed multiple times on the same J2EE server, and each instance of that same application can also be stopped, started, upgraded, tweaked, and managed entirely independent of any other instances of that same Java application.

What has this to do with ColdFusion? ColdFusion MX is actually not a server; technically it's an application, a Java application that runs on top of a J2EE server. And like any Java application running on a J2EE server, you may deploy multiple instances of ColdFusion MX on the same physical hardware, multiple instances that are entirely independent of each other.

The Benefits
What are the benefits of running multiple instances of ColdFusion MX on J2EE? There are lots, some obvious and some less so:

A ColdFusion instance cannot step on the feet of any other ColdFusion instance. That bad SQL statement that someone else wrote need no longer hurt the performance of your application.

Each ColdFusion instance has its own ColdFusion Administrator and its own ColdFusion settings. The owner of each ColdFusion instance can safely make ColdFusion Administrator changes that will not affect other instances.

ColdFusion instances can be upgraded independent of each other.

Multiple instances are more secure than a single shared instance.

Most J2EE servers (including Macromedia JRun) allow you to cluster instances on the same box. In other words, you can have multiple copies of the same ColdFusion application (each running in a separate ColdFusion instance) on the same machine, and cluster them so that you have application failover on a single box.

ColdFusion even allows the SESSION scope to be clustered. In the past (ColdFusion 4 and 5) it was close to impossible to use SESSION and clustering at the same time. You either had to use CLIENT variables and write them to a shared database, or use some sort of sticky IP to essentially prevent clustering while a SESSION was active. ColdFusion MX on top of J2EE leverages Java sessions that can be clustered (on some J2EE servers). As such, ColdFusion SESSION variables (with the notable exception of CFCs) can be shared across ColdFusion instances (on the same box or even on different boxes).

In other words, you get all the functional benefits that you'd get by running ColdFusion on multiple servers (without needing multiple servers), you get the ability to cluster your applications even on a single box, you get dramatically improved session state support in clusters, and the best part is... you don't need to buy a copy of ColdFusion for each instance. The ColdFusion license allows for as many instances as you'd like on the same server. So, you get all of the listed benefits, and cost savings too.

So, How Many Instances?
Now that you know that you can create as many instances as you'd like, the next question is, should you? You can use ColdFusion MX for J2EE as you do standalone ColdFusion, lots of applications in a shared instance. You can also create multiple instances. Or you can do both.

I've already listed all the pros to creating multiple instances of ColdFusion, but there is an important con - each instance is a full ColdFusion install running a full version of ColdFusion. As such, each additional instance requires additional system resources, about 100MB RAM (or so) per instance. RAM is pretty cheap nowadays, but even so, having hundreds of instances is probably very impractical. (An ISP, for example, hosting several hundred ColdFusion clients on a single box, will probably not create an instance for each and every client.)

The ideal number of instances is really dependent on your application and needs. You may have applications that can share an instance. You may have some applications that need their own instances. You may even have applications that each require multiple instances. The key is that you have the flexibility to do whatever works best for you. ColdFusion supports it, and makes it remarkably cost effective too.

Getting Started By now you probably do not need any more convincing of the value of ColdFusion of top of J2EE. If you are itching to get started, here are some things to keep in mind:

Obviously, you'll need a J2EE server. Popular choices include IBM WebSphere, BEA WebLogic, Sun ONE, and our own Macromedia JRun. If you are not yet running a J2EE server then look at JRun - not only is it the most economical commercial J2EE implementation, you'll also find it to be the easiest to install and configure.

Once you're running a J2EE server you'll need to install ColdFusion on top of it. Installing ColdFusion for J2EE is very different from installing standalone ColdFusion. J2EE applications are installed using special files (EAR or WAR files) that contain entire applications. These files are expanded and processed by management software provided with the J2EE server (and each J2EE is different of course). The process of installing ColdFusion involves running the ColdFusion installer program which creates an EAR or WAR file, and then using the J2EE server management tools to deploy the created EAR or WAR file.

For what it's worth, servers like JRun will allow you to deploy ColdFusion as an EAR file or as a WAR file. EAR files can contain more resources than a WAR file can, but that's not really relevant to ColdFusion installs. From a ColdFusion perspective, the advantage to using WAR files is that using an EAR file you'd need to run the ColdFusion installer to generate a unique EAR file for each instance, and using WAR files you can reuse the same WAR file repeatedly.

When you install a J2EE application (an EAR or a WAR) it's installed into a virtual path called a context root. So, path http://myserver/app1/ would point to the app1 context root, and http://myserver/app2 would point to the app2 context root. It is the context root in a URL that tells the J2EE server which application to use. Each application (and thus each instance of ColdFusion) goes into its own context root. If you are deploying a WAR file the management interface will prompt for the context root to use at deployment time. If you are deploying an EAR file then the ColdFusion installer will prompt for the context root, which will be embedded in the EAR file itself (this is why I said that using WAR files to deploy ColdFusion is advantageous in that the same WAR file could be used for each instance).

It is possible to have ColdFusion MX run in the default context (/ without a specified context root in every URL). The exact steps to configure this vary based on the J2EE server being used, so consult your J2EE server documentation.

Most J2EE servers (including JRun) allow application instances to be bound to different virtual hosts so that you do not need to always use the context root. Unfortunately, this tends to be very J2EE implementation specific, so consult your J2EE server documentation. JRun, for example, supports the ability to deploy multiple applications at the default context path so long as each is deployed into a different virtual host.

Each instance of ColdFusion gets its own copy of the ColdFusion Administrator, Flash Remoting, and other ColdFusion features and technologies. To invoke the correct ColdFusion Administrator, for example, you just need to be sure to use the right context root in the URL.

Clustering J2EE applications is also very J2EE implementation specific. JRun, for example, comes with an interface called the JMC (JRun Management Console), which has a series of screens that walk you through cluster creation. Again, consult your J2EE server documentation.

If all this sounds foreign to you, don't panic. While installing and configuring ColdFusion on top of J2EE is not (and cannot be) as simple as installing standalone ColdFusion, it's actually not that painful either (especially if you are running JRun). And Macromedia is committed to making the process even easier in the future.

Summary
ColdFusion now comes in two distinct flavors, standalone ColdFusion and ColdFusion for J2EE. Although all versions of ColdFusion run on top of J2EE servers (standalone ColdFusion has a scaled down version of JRun embedded within it), the ability to run multiple instances requires ColdFusion on top of a J2EE server. For many organizations, the security, scalability, stability, manageability, and cost savings of running multiple instances of ColdFusion are the compelling reasons to upgrade not just to ColdFusion MX, but to ColdFusion MX for J2EE.

Note:
This entire discussion pertains to Coldfusion MX for J2EE. Standalone Coldfusion does not support the running of multiple instances on a single server.

About Ben Forta
Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.