Environment variables in J2EE world

Right Java tools for J2EE, Web Service, Grid and more

Environment variables in J2EE world

Overview

In the EJB world, the environment values are very rigid. They are in deployment descriptors in env-entry elements.

For example, you define as:

<env-entry>

<env-entry-name>foo/name4</env-entry-name>

<env-entry-type>java.lang.Integer</env-entry-type>

<env-entry-value>10</env-entry-value>

</env-entry>

The environment value can be changed at deploy time only. They are not shareable among different distributed components.

GlobalEnvironment is a global version of regular Properties and Hashtable. java.util.Properties and java.util.Hashtable are valid within one single Java VM. GlobalEnvironment is valid across the whole network in distributed computing environment.

What is GlobalEnvironment

GlobalEnvironment is a family of utility classes. It consists of:

GlobalDouble

GlobalHashtable

GlobalLong

GlobalObject

GlobalProperties

This family provides globally shared key-value pairs. These pairs are available for different

Java threads

JVMs,

EJBs (Enterprise Java Beans)

JSPs (Java Server Pages)

Java applications

non-Java applications.

See GlobalProperties for details.

GlobalEnvironment can be used as static values to initialize all your J2EE components.

GlobalEnvironment can be used as dynamic values as well to represent the state of your application. It will be monitored easily.

GlobalEnvironment in not only thread safe, but thread friendly as well. It provides method increase( ). A thread will not over write changes from other threads. For example, you have an attribute "totalSale". The current value is 10.00. Now you sold something for 2.00 and your coworker sold something for 5.00 at the same time. If you do:

  
    read totalSale and get the value 10.00
    write totalSale as 10.00 + 2.00

and your coworker does similar thing. Than the result will be either 12.00 or 15.00, not 17.00.
If you use method increase, do not read, do not write, but:

    increase by 2.00

and your coworker does similar thing. The result will be 17.00, regardless who gets the transaction first.

Other options

When we come to this point, you may say that there is a performance penalty to access the database dynamically. Yes, if compared to memory operation in a single JVM. But if you want the key-value pairs valid across the network for different JVMs, you need to keep them in a central place. If you want they be persistent, you need store them in a data source. Database is the best choice.

Some programs store user objects in JNDI tree. But that is even more expensive. Many clustering use multicast for clustering communications. Storing large objects within the JNDI tree can overload multicast traffic and interfere with the normal operation of a cluster. If the owner of the data (the instance of program who puts the data into JNDI tree) goes out the scope, your J2EE server may remove that data from JNDI tree.

Some programs store user objects in HttpSession. An HttpSession must be read by the servlet whenever it is used and rewritten whenever it is updated. This involves data serializing, reading, and writing. In most applications, each servlet requires only a fraction of the total session data. If a large object graph is stored in HttpSession there will be some performance penalty.

There is a new class Preference in JDK 1.4. But neither JNDI or Preference will allow you to combine environment changes and your business data changes in one transaction, so you can not COMMIT or ROLLBACK.

GlobalEnvironment is an open source program

It comes with Apache license and can be downloaded anonymously from www.ACElet.com/download.