Make web site - CHAPTER 13 Optimizing fetching and caching have to
CHAPTER 13 Optimizing fetching and caching have to decide, for each persistent class and collection, which cache concurrency strategy to use if you want to enable the second-level cache. The four built-in concurrency strategies represent decreasing levels of strictness in terms of transaction isolation: Transactional Available in a managed environment only, it guarantees full transactional isolation up to repeatable read, if required. Use this strategy for read-mostly data where it s critical to prevent stale data in concurrent transactions, in the rare case of an update. Read-write This strategy maintains read committed isolation, using a time- stamping mechanism and is available only in nonclustered environments. Again, use this strategy for read-mostly data where it s critical to prevent stale data in concurrent transactions, in the rare case of an update. Nonstrict-read-write Makes no guarantee of consistency between the cache and the database. If there is a possibility of concurrent access to the same entity, you should configure a sufficiently short expiry timeout. Otherwise, you may read stale data from the cache. Use this strategy if data hardly ever changes (many hours, days, or even a week) and a small likelihood of stale data isn t of critical concern. Read-only A concurrency strategy suitable for data which never changes. Use it for reference data only. Note that with decreasing strictness comes increasing performance. You have to carefully evaluate the performance of a clustered cache with full transaction isolation before using it in production. In many cases, you may be better off disabling the second-level cache for a particular class if stale data isn t an option! First benchmark your application with the second-level cache disabled. Enable it for good candidate classes, one at a time, while continuously testing the scalability of your system and evaluating concurrency strategies. It s possible to define your own concurrency strategy by implementing org. hibernate.cache.CacheConcurrencyStrategy, but this is a relatively difficult task and appropriate only for rare cases of optimization. Your next step after considering the concurrency strategies you ll use for your cache candidate classes is to pick a cache provider. The provider is a plug-in, the physical implementation of a cache system.
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.