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.

Read the advice and real-world experiences of J2EE experts for simplifying the J2EE development life cycle.

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.

Publishing Schedule is as follows:

Step 1: Slicing and Dicing J2EE
Ted Neward, author, Effective Enterprise Java

Step 2: Managing J2EE Projects
Julien Dubois, Senior J2EE Developer

Step 3: Design and Modeling
Scott W.Ambler, Senior Consultant, Ronin International

Step 4: Building on Frameworks
Andrei Cioroianu, Founder of Devsphere

Step 5: Building More Usable Software
Jonathan Boutelle and Rashmi Sinha (Ph.D), Principal, Uzanto Consulting

Step 6: Mastering Server-Side Java
Venkat Tipparam, Oracle Java Developer of the Year 2004

Step 7: Mastering Server-Side Java (Part 2)
Rod Johnson, co-author, Spring Framework; and James Clark, Oracle TopLink Development.

Step 8: Designing Better User Interface
Hans Bergsten, member JCP expert groups, and Author of JavaServer Faces (O’Reilly)

Step 9: Designing Better User Interface (Part 2)
Craig McClanahan, Creator of Struts

Step 10: Mastering the Art of Debugging
Satadip Dutta, Software Architect, Hewlett-Packard

Step 11: Optimizing and Profiling
Benjamin Livshits, Ph.D. candidate, Stanford University

Step 12: Deploying
Lonneke Dikmans, Senior Consultant, Transfer Solutions

.. 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!

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

"Mastering J2EE" and Oracle, what a classic oxymoron...

Look, Oracle, you need to do some internal work on "Mastering J2EE" yourself.

I've always said in the past, companies which promote sub-standard products based on Java does incredible harm to the community.

Yet, Oracle can sale anything and make billions, no matter how horrible the product, let's see what PeopleSoft will look like soon...

it could be good if they provide a printable version of theri documents on the web site.
does any one from ORACLE will take a look at this forum ? ;)

You can print any article by using the "Printer View" button (which can be found way at the bottom right hand corner of any article).

In addition, we will be publishing "pdf" version of every article shortly.

Thanks,
Sudhakar Ramakrishnan
Oracle Technology Network

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.

I am very glad to know that you found these articles very useful. Please send me your e-mail id and I will send the pdfs to you directly.

BTW: It shouldn't be too long before you see them online at http://www.oracle.com/technology/masterj2ee (stay tuned...)

Happy New Year!

Sudhakar Ramakrishnan
sudhakar.ramakrishnan@oracle.com

From "J2EE without EJB" page267

Caching of Persistent Data

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 :)

Regards,

José.

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.

Checkout Oracle Application Server Web Cache .

You might also be interested in Oracle Application Server Java Object Cache (a set of Java classes designed to manage Java objects within a process, across processes, and on local disk.)

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.