2.1. Overview

The two components in JBossCache, plain cache (implemented as TreeCache) and PojoCache (implemented as PojoCache), are both in-memory, transactional, replicated, and persistent. However, TreeCache is typically used as a plain cache system. That is, it directly stores the object references and has a HashMap-like Api. If replication or persistency is turned on, the object will then need to implement the Serializable interface. In addition, it has known limitations:

Users will have to manage the cache specifically; e.g., when an object is updated, a user will need a corresponding API call to update the cache content.
If the object size is huge, even a single field update would trigger the whole object serialization. Thus, it can be unnecessarily expensive.
The object structure can not have a graph relationship. That is, the object can not have sub-objects that are shared (multiple referenced) or referenced to itself (cyclic). Otherwise, the relationship will be broken upon serialization. For example, Figure 1 illustrates this problem during replication. If we have two Person instances that share the same Address , upon replication, it will be split into two separate Address instances (instead of just one).

Figure 2.1. Illustration of shared objects problem during replication

PojoCache, on the other hand, is a fine-grained "object-oriented" cache. By "object-oriented", we mean that PojoCache provides tight integration with the object-oriented Java language paradigm, specifically,

no need to implement Serializable interface for the POJOs.
replication (or even persistency) is done on a per-field basis (as opposed to the whole object binary level).
the object relationship and identity are preserved automatically in a distributed, replicated environment. It enables transparent usage behavior and increases software performance.

In PojoCache, these are the typical development and programming steps:

Declare POJO to be "prepared" (in Aop parlance) either through an external xml file (i.e., jboss-aop.xml), or through annotation inside the POJO. Depending on your preference, you can either pre-instrument your POJO (compile time) or have JBossAop do it at load time.
Use putObject Api to put your POJO under cache management.
Operate on POJO directly. Cache will then manage your replication or persistency automatically.

More details on these steps will be given in later chapters.

PojoCache also extends the functionality of TreeCache to object based. That is, the TreeCache features such as transaction, replication, eviction policy, and cache loader, has been extended to POJO level. For example, when you operate on a POJO (say, pojo.setName()) under a transaction context, it will participate in that transaction automatically. When the transaction is either committed or rolled back, your POJO operations will act accordingly.

Finally, PojoCache can also be used as a plain TreeCache . For example, a user can use the TreeCache API [e.g., get(String fqn) and set(String fqn, String key, String value) ] to manage the cache states. Of course, users will need to consider the extra cost (albeit slight) in doing this.