Oracle Technology Network (OTN) launched "Mastering J2EE Application Development Series," a 12-week series of technical articles providing expert advice and best practices on how developers can simplify the J2EE application development life cycle in 12 easy steps.

.. how developers can simplify the J2EE application development life cycle in 12 easy steps .. This week: Learn how to synchronize in-memory caches among servers in a J2EE cluster to improve performance and scalability of server-side Java applications.

Nice touch of irony, that "how developers can simplify" means the additional entropy of custom caching code and extra JMS configuration issues, when the task at hand is as simple as using Coherence or any other off-the-shelf caching solution. (And for the half dozen companies using the Oracle application server, it's already got some caching built in!)

Next week on OTN: Need to store data using SQL? Want a simpler way than just using Oracle? We'll show you how to write your own database engine!

thank you , but i mean a clean printable version ,with pictures for example .hope i can see a link to a clean pdf version soon.i found these articles very usefull , so looking for a printable is not something far from mind.

The single biggest booster of data access performance in typical application is aggressive caching.Particulary if persistent data is just read and written by one single process – for example, in case of a web content management system – caching is highly advisable: No other process will modify the data, so there is no potential staleness involved as long as the application itself properly notifies the cache of changes to persistence objects.

Of course, caching is not appropriate for data that is frequently updated by various process, as the database then needs to be hit on each request to avoid the danger of stale results. For read-mostly objects, particulary reference data like user profiles or product categories, caching may still be a good fit. Of course in some applications, any risk of staleness may be unacceptable. Tolerence of staleness depends on the nature of the data.

A special scenario arises with clustered servers in that a distributed cache is needed for proper cache coherence. If the application itself changes persistent objects on one server, all other instances of the cache need to be notified.Distributed caching is a very tricky issue; often it is advisable to turn off caching for edata that is not not allowed to be stale in a cluster, delegating the burden of data coherence to the database.Many caching solutions, like EHCache, are not primary intended for distributed caching.There is a new open source project called SwarmCache that addresses distributed caching. This is the domain of Tangosol Coherence (a highly optimized commercial solution).

Many developers incorrecly assume that entity beans provide the best solution for distributed caching. In fact, even the best entity implementations, such as the WebLogic implementation, offers less sophisticated distributed cahing out the box than a combination of an O/R mapper such as Hibernate ot Kodo JDO and a distributed cache such as Coherence.

And I would add that most of the projects I have worked on so far required zero tolerence with regards to staleness of some frequently used data.With such requirements, there is less chance to use the approach you are suggesting in this article: distributed caching.

Remember the First Law of Distributed Computing: Don’t Distributed Your Objects :)

Caching is a state-of-art server acceleration solution. I think most developers do understand the value of caching and compression. Imagine making requests to the origin servers for every request.

That said, dynamic applications need to scale and there are a number of tools that can help you manage your site for high performance/scalability. You might consider caching, clustering, deploying to grid based architecture etc.

There are also a number of technologies present to handle to level of volatility your content forces on your architecture. Depending on the kind of cache you use, you can define caching policies (which content to cache, which not to cache).

Cache invalidation and expiration is another topic of interest (it is hard to have everything covered in one article.) Depending upon your architecture, you might need to enforce different kind of caching policies that invalidate content.

In terms of more product information specific to Oracle, here are some resources.

Oracle Application Server for example has its own caching built-in and provides a cache-consistency model enabling you to purge cached content. Pages that are not cacheable in full might be strong candidates for partial-page caching (ESI - Edge Side Includes). In fact there is a JSR - 128, extension for Java.

The article demonstrated aspects of server-side development that you can master using caching as an example. The example touches on a number of mainstream J2EE technologies server-side developers use. Many of them are proven concepts.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.