CHAPTER 13 Optimizing fetching and caching accessed by
CHAPTER 13 Optimizing fetching and caching accessed by concurrently running threads, obviously with implications on transaction isolation. Cluster scope cache Shared between multiple processes on the same machine or between multiple machines in a cluster. Here, network communication is an important point worth consideration. A process scope cache may store the persistent instances themselves in the cache, or it may store just their persistent state in a disassembled format. Every unit of work that accesses the shared cache then reassembles a persistent instance from the cached data. A cluster scope cache requires some kind of remote process communication to maintain consistency. Caching information must be replicated to all nodes in the cluster. For many (not all) applications, cluster scope caching is of dubious value, because reading and updating the cache may be only marginally faster than going straight to the database. Persistence layers may provide multiple levels of caching. For example, a cache miss (a cache lookup for an item that isn t contained in the cache) at the transaction scope may be followed by a lookup at the process scope. A database request is the last resort. The type of cache used by a persistence layer affects the scope of object identity (the relationship between Java object identity and database identity). Caching and object identity Consider a transaction-scoped cache. It seems natural that this cache is also used as the identity scope of objects. This means the cache implements identity handling: Two lookups for objects using the same database identifier return the same actual Java instance. A transaction scope cache is therefore ideal if a persistence mechanism also provides unit of work-scoped object identity. Persistence mechanisms with a process scope cache may choose to implement process-scoped identity. In this case, object identity is equivalent to database identity for the whole process. Two lookups using the same database identifier in two concurrently running units of work result in the same Java instance. Alternatively, objects retrieved from the process scope cache may be returned by value. In this case, each unit of work retrieves its own copy of the state (think about raw data), and resulting persistent instances aren t identical. The scope of the cache and the scope of object identity are no longer the same. A cluster scope cache always needs remote communication, and in the case of POJO-oriented persistence solutions like Hibernate, objects are always passed
Searching for affordable and reliable webhost to host and run your web applications? Go to our java web server services and you will be pleased.