6

On the DD4T website it states that caching has been improved in version 2.0. However I can't find anywhere what the changes are.

I have been playing around with the CallBack settings and did not notice any effect. Looking at the code it looks like the callback functionality has been removed from the DefaultCacheAgent. Also in the ConfigurationKeys class no CallBack related keys are present.

My conclusion is that the following setting is obsolete as per DD4T 2.0:

<add key="CacheSettings_CallBackInterval" value="30" />

It seems with the introduction of the TridionBackedCacheAgent, which offers event based cache invalidation, the DefaultCacheAgent has been updated to a simple timebased cache.

Can anyone confirm this and explain other caching improvements made in 2.0?

Improve this question
1
  • Sidestepping to DXA; note that DXA 1.3 uses the DefaultCacheAgent in a hardcoded way.
    – Jeroen Suurd
    Apr 8, 2016 at 2:09

1 Answer 1

Reset to default
3

As highlighted in Albert's DD4T and caching blog post from back in 2012, the earlier versions of DD4T (prior to v2.0) relied on three mechanisms for caching:

  1. ASP.NET Output Cache
  2. SDL Tridion Object Cache
  3. The inbuilt DD4T caching

As you say, the inbuilt DD4T caching polled the Content Delivery Store periodically to see whether the items stored in its cache were still valid. The time between each of these pollings was defined in the CacheSettings_CallBackInterval setting (in seconds).

With the arrival of DD4T v2.0, the in-build, time based caching was removed in favour of event based cache invalidation (for both the .NET and the Java versions).

The new approach uses JMS as a mechanism for synchronisation of the caches. This relies on Synchronising the Tridion Object Caches using Java Message Service, rather than the more common RMI.

JMS provides real-time invalidation of the DD4T cache. It also has the advantage (over RMI - as used by default for the Cache Channel Service) of working over HTTP and being able to operate on fixed ports - thus making firewall configurations easier.

The caching has now been removed from the DD4T Core, and is installed and configured separately as an extension. The C# version can be downloaded from NuGet here and the Java version from Maven here.

For reference, there is also a useful section for Using JMS cache invalidation in the Quick Start guide for DD4T 2 Java.

Hope this helps!

Improve this answer
4
  • Can I still use RMI with DD4T 2.0 instead of JMS?
    – rdhaundiyal
    Jan 9, 2017 at 20:06
  • 1
    I have never implemented it this way, but I suspect that if you don't use the new DD4T caching extension then it will just use the Tridion object caching - which can be configured to just use RMI. Of course this may mean that you have to implement your own application level caching if just using the Tridion Object Caching isn't performant enough.
    – Jonathan Williams
    Jan 9, 2017 at 23:25
  • Thanks Jonathan, but in that case i will not be able to leverage the benefit of DD4T cache. In that case i do not even have to set the call back interval. Could you please confirm.
    – rdhaundiyal
    Jan 10, 2017 at 11:43
  • 1
    Yes, that is my understanding too. Looking at Jeroen's question above, he tried to set the CacheSettings_CallBackInterval but this didn't do anything.
    – Jonathan Williams
    Jan 10, 2017 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.