From 47fdac92143b0e9ed6485617fa22d7cfceb2b460 Mon Sep 17 00:00:00 2001 From: Stephane Nicoll Date: Mon, 9 Feb 2015 10:09:12 +0100 Subject: [PATCH] Clarify the use of @Cacheable in PostConstruct code Update documentation to explicitly mention that the cache interceptor must be fully initialized to provide the expected behavior and therefore initialization code should not rely on this feature, i;e. typically in PostConstruct callback. Since the Transactional infrastructure has the exact same infrastructure, update that section of the doc as well. Issue: SPR-12700 --- src/asciidoc/index.adoc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/asciidoc/index.adoc b/src/asciidoc/index.adoc index 6700d8ad268..e8b86991b82 100644 --- a/src/asciidoc/index.adoc +++ b/src/asciidoc/index.adoc @@ -23871,7 +23871,9 @@ transactional proxy, which would be decidedly __bad__. In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual -transaction at runtime even if the invoked method is marked with `@Transactional`. +transaction at runtime even if the invoked method is marked with `@Transactional`. Also, +the proxy must be fully initialized to provide the expected behaviour so you should not +rely on this feature in your initialization code, i.e. `@PostConstruct`. ==== Consider the use of AspectJ mode (see mode attribute in table below) if you expect @@ -49737,7 +49739,9 @@ In proxy mode (which is the default), only external method calls coming in throu proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual caching at runtime even if the invoked method is marked with `@Cacheable` - considering -using the aspectj mode in this case. +using the aspectj mode in this case. Also, the proxy must be fully initialized to provide +the expected behaviour so you should not rely on this feature in your initialization +code, i.e. `@PostConstruct`. ====