From 29a6d24d6587ecbe340e4ec65f977395d2d0f329 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 d28e9992ac..4d0d467652 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 @@ -49741,7 +49743,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`. ====