Java Object Caching with EHCACHE

EHCache is a pure Java, in-process cache available on Source-Forge. It is the default pluggable cache for Hibernate 3.0. In light of the fact that support for Java Caching System is being removed from Hibernate, EHCache gains some extra notice. EHCache supports Less Frequently Used (LFU), First-In-First-Out (FIFO) algorithms in addition to Least Recently Used (LRU) algorithm for cache eviction. The following types of cache stores are supported in EHCache:

• Memory cache
• Disk Cache
• Distributed cache

The following description of the features in EHCache that meet our requirements

• Dependencies: For JDK1.4, JDK1.5 and JDK 1.6, EHCache requires commons-logging and commons-collections 2.1.1 from Apache's Jakarta project.
• Element grouping: Element grouping is not supported in EHCache. The only level of grouping allowed in EHCache is at the cache level. A single cache manager can manage multiple caches.
• Data Expiration: Data expiration can be set declaratively as well as programmatically at the cache level. EHCache does not provide support for setting expiration values at the element level.
• Configurable runtime properties: Runtime parameters can be configured in the xml file, which can be defined externally. The XML file has to conform to the schema defined in the ehcache.xsd. The properties that can be configured at the region level include maximum objects, cache name, size, shrink interval etc.
• Element event handling: EHCache allows to attach event handlers to the cache manager (cache add, remove) and the cache (put, update, remove).

I did not provide any code samples here because the invocation is quite straight forward and the configuration values are similar to that of Java Caching System except that they will be defined in XML instead of property file. All the documentation for EHCACHE is found in one place.

Java Object Caching with Java Caching System

Java Caching System is a distributed caching system written in Java. In this post I discuss the basic overview of how to use JCS and point to the relevant parts of the documentation of the product for further information. Most of the information has been gathered and organized from the site. The foundation of JCS is the composite cache.Four types of caches can be plugged into the Composite Cache for any given region:

• LRU Memory Cache: An extremely fast, highly configurable memory cache. It uses the Least recently used algorithm to manage the number of items that can be stored in the cache.
• Indexed disk cache: Fast, reliable and highly configurable swap for cached data. Cache elements are written to disk via a continuous queue-based process. Every aspect fo the disk cache is configurable, and a thread pool can be used to reduce the number of queue worker threads across the system.
• TCP Lateral cache: Provides an easy way to distribute cache data into multiple servers. Uses a UDP discovery mechanism so that the entire farm need not be reconfigured when a new node is added. Each node maintains a connection to every other. TCP lateral can be configured to change most interactions each node has with it's peers.
• RMI Remote cache: A remote cache server can be configured as a central connection point for all the nodes instead of each maintaining a connection with the every other node. The remote server broadcasts events (updates, invalidations etc.) generated on one node to the others. The remote cache server holds a serialized version of your objects, so it does not need to be deployed with your class libraries.

Writing code for the Java Caching system is quite simple.

import org.apache.jcs.JCS;
import org.apache.jcs.access.exception.CacheException;
. . .
private static final String cacheRegionName = "city";
private JCS cache = null;
. . .
// in your constructor you might do this
try {
setCache( JCS.getInstance( this.getCacheRegionName() ) );
} catch ( CacheException e ) {
log.error( "Problem initializing cache for region name ["
+ this.getCacheRegionName() + "].", e );
}
. . .
// to get a city out of the cache by id you might do this:
String key = "cityId:" + String.valueOf( id );
City city = (City) cache.get( key );
. . .
// to put a city object in the cache, you could do this:
try {
// if it isn't null, insert it
if ( city != null ) {
cache.put( key, city );
}
} catch ( CacheException e ) {
log.error( "Problem putting "
+ city + " in the cache, for key " + key, e );
}

The following is a small description of how the requirements that I outlined in the caching requirements post can be implemented using JCS.

• Dependencies: As of version 1.2.7.0, the core of JCS (the LRU memory cache, the indexed disk cache, the TCP lateral, and the RMI remote server) requires only two other jars.
  • concurrent
  • commons-logging
  Versions 1.2.6.9 and below also require the following two additional jars:
  • commons-collections
  • commons-lang
• Element grouping:The JCS provides feature rich grouping mechanism, where groups of elements can be invalidated and whose attributes can be listed.
• Data expiration: Data expiration can be controlled at the individual element level. This can be achieved declaratively as well as programmatically. In order to declare the expiration charecteristics within a region, add the following under the region definition.

  
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLifeSeconds=700
jcs.default.elementattributes.IdleTime=1800
jcs.default.elementattributes.IsSpool=true
jcs.default.elementattributes.IsRemote=true

  
  This applies to all elements within a region and if declared in the defaults, will apply to elements in all regions.
  In order to programmatically set the expiration properties, then you can do so using IElementAttributes as shown below:
  

  // jcs.getDefaultElementAttributes returns a copy not a reference
IElementAttributes attributes = jcs.getDefaultElementAttributes();
// set some special value
attributes.setIsEternal( true );
jcs.setDefaultElementAttributes( attributes );


  
  
• Configurable runtime parameters: Runtime parameters can be configured in the cache.ccf file. The parameter that can be configured at the element level are discussed in the element sections. The configuration properties that can be set at the region level are discusses here. The properties that can be configured at the region level include maximun objects, cache name, size, shrink interval etc. An example is shown below

  
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=200001
jcs.default.cacheattributes.MemoryCacheName=
org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.default.cacheattributes.UseMemoryShrinker=true
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.elementattributes=
org.apache.jcs.engine.ElementAttributes


• Disk overflow (and defragmentation)
  Thread pool controls
  Region data separation and configuration
  More information on configuring auxilaries can be found on the site as they have extensive configurable properties.
• Element event handling: JCS allows to attach event handlers to elements in the local memory cache (does not work for auxilaries, i.e. lateral, remote and disk caches). To create an event handler you must implement the org.apache.jcs.engine.control.event.behavior.IElementEventHandler interface. This interface contains only one method:

  public void handleElementEvent( IElementEvent event );

  
  The IElementEvent object contains both the event code and the source. The source is the element for which the event occurred. Once you have an ElementEventHandler implementation, you can attach it to an element via the Element Attributes as shown below

  MyEventHandler meh = new MyEventHandler();
// jcs.getDefaultElementAttributes returns a copy not a reference
IElementAttributes attributes = jcs.getDefaultElementAttributes();
attributes.addElementEventHandler( meh );
jcs.put( "key", "data", attributes );


• Fine grained element configuration options: As discussed above.
  
• Non-blocking "zombie" (balking facade) pattern:
  Lateral distribution of elements via HTTP, TCP, or UDP
  UDP Discovery of other caches
  JCS uses the zombie pattern in the Lateral TCP Cache auxilary. More information may be found here.
  
• Remote synchronization
  Remote store recovery
  Remote server chaining (or clustering) and failoverInformation about the configuration options for clustering can be found at Remote auxilary caching

Free Database Versions: IBM, Oracle and Microsoft

Oracle announced the general availability of the free version (Oracle 10g Express edition) of their database product following microsoft(SQL Server Express edition) and IBM (DB2 Express-C). This product supports Oracle Call Interface for C and C++, Oracle HTML DB, ODBC, Oracle Data Provider for .NET, OLE DB, JDBC, and PHP development environments. The following are a few features of the product:

1. Available on 32-bit Linux and Windows Installs using native installers
2. English (single byte character set) and International (Unicode) versions available with support for 10 major languages
3. Supports up to 4GB of user data
4. May be installed on a server with any amount of memory, but will only use up to 1GB RAM of available memory
5. Fully upgradeable to other Oracle Database 10g editions
6. Oracle Text for efficient text-based searches

An Oracle Java developer's guide is also provided along with an Oracle 10g express edition getting started guide. Although all three come with a free to develop, deploy and distribute licenses, they have a few restrictions. The following is a list of restrictions for the free version of databases provided by IBM, Microsoft and Oracle.
Oracle 10g Express edition

• Processors: Can be installed on multiple CPU Server but will use only ONE CPU.
• Memory: A maximum of 1GB memory will be used (Even if you have more).
• Database size: Up to 4GB user data.

Microsoft SQL Server Express edition

• Processors: 1 CPU, but can be installed on any server
• Memory: 1 gigabyte (GB) addressable RAM
• Database Size: 4 GB maximum database size

IBM DB2 Express-C

• Processors:Upto 2 dual-core processors.
• Memory: A maximum of 4GB addressable memory.
• Database Size: Unlimited

Looking at this, if you are planning on using a free database for you application, it looks like DB2 Express-C is the clear will with respect to database size and memory availability.

Java Object Caching: Requirements

This is a follow-up of the Java Object Caching post that was posted on March 1st. As mentioned earlier, Object Caching refers to caching objects that are neither fully static not fully dynamic. There are a few Object Caching services available under the Apache License, and are quite easy to plug into your applications. The following is a list of features that may be available in a caching service, which can be used as a guide for determining the right requirements of a caching tool for your needs:

1. Minimal dependencies
2. Element grouping
3. Quick nested categorical removal
4. Data expiration: idle time, max life
5. Configurable runtime parameters
6. Security: Authentication or authorization should be completed before objects return from the cache. The information transmitted between caches should be encrypted.
7. Disk overflow (and defragmentation)
8. Thread pool controls
9. Region data separation and configuration
10. Element event handling
11. Fine grained element configuration options
12. Remote synchronization
13. Remote store recovery
14. Scheduled cache expiry
15. Non-blocking "zombie" (balking facade) pattern: When using distributed caching, Puts and removals are queued and occur asynchronously in the background, and hence are non-blocking. Get requests are synchronous and can potentially block if there is a communication problem.
16. Lateral distribution of elements via HTTP, TCP, or UDP
17. UDP Discovery of other caches
18. Remote server chaining (or clustering) and failover
19. Reliability
20. Maintainability

These are a few general issues when considering caching services. The specific application may have a superset or a subset or a combination with other requirements.

Yahoo Design Patterns Library

This has been around for a while but I just came across , but in case you haven't seen it and you're doing web-based development, you really should check out the Yahoo Design Patterns Library. It is a part of the Yahoo! developer network (something really new to me, as I did not go to yahoo for a while). It's simply an excellent resource for web developers. I just went through a part of the site and here is a part of some interesting stuff going on in the yahoo developer network ...

1. The JavaScript developer center: This section provides a lot of articles and documentation on how to use JavaScript with yahoo! products and services and also many code samples you can learn (wink, wink) from and make use of in your own web and client applications.
2. The UI Library: The Yahoo! User Interface Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX. All the components in the Yahoo! User Interface Library have been released as open source under a BSD license and are free for all uses.
3. The Widget engine: The Yahoo! Widget Engine (formerly known as Konfabulator) is a JavaScript runtime engine for Windows and Mac OS X, which help you create widgets for your desktop such as clocks, calculators, stock tickers etc.
4. Maps API: There are three API families for Yahoo! maps - AJAX, Flash, and the original Simple API.
5. The PHP developer center: As you might have known, Yahoo! runs PHP, and naturally have a PHP developer center where they provide HOWTO articles, code samples, and community resources for using Yahoo! Web services with PHP.

This is but a very small part of their developer center. You can access a host of other REST based web services for almost all their products, including flickr, de.icio.us etc. The Yahoo! web services blog provides up-to-date information of the services provided by yahoo. The Yahoo! developer community section contains links to sample applications implemented by other Yahooo! developers and also support groups for each of the product web service sections.

WebSphere Application Server Security Flash

WebSphere Application Server Support has issued a security flash: Security: Possible security exposure with JSP source code on IBM WebSphere Application Server Version 5 (PK13792 and PK20181) here are the details:

Under some circumstances, the JavaServer Pages (JSP) source code is returned instead of the formatted output.

Affected versions: WAS 5.0.2.x and 5.1.1.x
Does not affect WAS 6.x

Interim Fixes have been released for the affected versions.
Interim Fix PK13792 (PK13792_50210_50215.jar) - For WebSphere Application Server 5.0.2.x
Interim Fix PK13792 (PK13792_5114_5118.jar) - For WebSphere Application Server 5.1.1 cumulative fix 4 through cumulative fix 8.
Interim Fix PK20181 (PK20181_5119.jar) - For WebSphere Application Server 5.1.1 cumulative fix 9.

These fixes will be rolled into the next cumulative release. The future cumulative fixes for the affected product versions will include these fixes.

To get notified of announcements like this in the future, subscribe to IBM's RSS feed for WAS.

Java Object Caching:

Object caching is an important aspect in the design and development of Web Applications. Object caching is for objects which are neither static (unchanging) nor fully dynamic. The best definition of object caching can be found in the functional specification document for Object Caching Service for Java OCS4J, which says ...

A server must manage information and executable objects that fall into three basic categories: objects that never change, objects that are different with every request, and everything in between. Java is well equipped to handle the first two cases but offers little help for the third. If the object never changes, we create a static object when the server is initialized. If the object is unique to every request, we create a new object each time. For everything in between, objects or information that can change and are shared across requests, between users or between processes, there is the "Object Caching Service."

Object Caching appears to be similar to object pooling in many ways but, the difference is that pooled objects don't have any identity. While in case of pooling, we are looking for any object, possibly within certain characteristic constraints, in case of caching we are looking for a specific object with an identity and probably a state. The only purpose of object pooling is to prevent memory allocation. While object caching help improve application performance and scalability, it has some cost associated with it.

1. Consistency: Depending on the type of data that is being cached, the caching mechanism has to ensure consistency between the original and cached objects.
2. Durability: Changes made to the cache are likely to be lost (System cache).
3. Size: The memory used by cached objects needs to be maintained at a reasonable amount as is the case with HTTPSession too.

So how would you decide what objects to cache and what should not be cached. The following simple rules may be used as a guide.
Which objects may be Cached: Any data that does not change frequently and takes longer times to retrieve from the data source is a good candidate for caching.
What not to cache:

1. Secure information that can be accessed by other users on the web site. Like User profile information and other personal information, or credit card details.
2. Business information that changes frequently and causes problems if not up to date and accurate.