Essential ATG Dynamo Training - Got atg Certified Relationship Management Developer?
This is not an official ATG site: ATG, Dynamo, Scenario Server and Personalization Server are trademarks or registered trademarks of Art Technology Group
Articles Exercises Resources Links Search

What about Repository Caching?

What are the caching options for Repositories?

Where do you specify the caching options?

The default caching mode for an item descriptor is specified in the template definition file. This default is applied to all the properties of the item. Additionally you can specifically disable caching on a  per-property basis in the template definition file:

<item-descriptor name="person" cache-mode="locked">
   ...
    <table ...>
      <property name="balance" cache-mode="disabled"/>
   </table>
</item-descriptor>

How do the different caching options function?

No Caching

Values are cached within the current transaction, calling item.getPropertyValue("x") twice in the same transaction will not re-query the database. But subsequent calls outside of this transaction will re-query.

Simple Caching

The values are cached at the VM scope. All the calls to item.getPropertyValue("x") in the same VM will get the cached value. Changes made to the data by other servers or directly to the database are not reflected until the cache is invalidated.

Locked Caching

Locked caching requires a Lock Manager to be configured

read and write Locks

A central lock server hands out read and write locks for each item. There may be many readers but only on writer. getItem and getPropertyValue require only a read lock, setPropertyValue and getItemForUpdate require a write lock.

CHECK: Sounds like the call will block waiting for read locks to release

If you start off with a read lock then try to get a write lock, your cache may be stale since another thread may get the write lock first and modify the data. In this case a ConcurrentUpdateException (or IllegalArgumentException for setPropertyValue calls) is thrown.

writeLocksOnly

To avoid the ConcurrentUpdateException condition you can specify that the lock server should always issue write (exclusive) locks. This means that at a given time only one transaction (in the whole cluster) can read the data at any given time.

User information is a prime candidate for this since it's unlikely that multiple DRPs will be even reading the same pieces of user information at any given time.

<item-descriptor name="person" cache-mode="locked">
   <attribute name="writeLocksOnly" value="true"/>
   ....
</item-descriptor>

Distributed Caching

 

Under what circumstances should you use each of the caching modes?

Locked Caching Should be Used When

  • You have Scenario Server running over multiple DRPs

Configuring a Lock Manager

See the dynamo documentation for information on this it's all explained there.

 



Technical Training Advertise your Training Programs for Free! Los Angeles Web Design Shopping Cart Software  Form a Corporation