@@ -45718,7 +45718,7 @@ do yourself a favour and read <<expressions>>:
45718
45718
[source,java,indent=0]
45719
45719
[subs="verbatim,quotes"]
45720
45720
----
45721
- @Cacheable(value="books", **key="#isbn")**
45721
+ @Cacheable(value="books", **key="#isbn"**)
45722
45722
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
45723
45723
45724
45724
@Cacheable(value="books", **key="#isbn.rawNumber"**)
@@ -45728,7 +45728,7 @@ do yourself a favour and read <<expressions>>:
45728
45728
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
45729
45729
----
45730
45730
45731
- The snippets above, show how easy it is to select a certain argument, one of its
45731
+ The snippets above show how easy it is to select a certain argument, one of its
45732
45732
properties or even an arbitrary (static) method.
45733
45733
45734
45734
@@ -45739,8 +45739,8 @@ might depend on the given arguments). The cache annotations support such functio
45739
45739
through the `conditional` parameter which takes a `SpEL` expression that is evaluated to
45740
45740
either `true` or `false`. If `true`, the method is cached - if not, it behaves as if the
45741
45741
method is not cached, that is executed every since time no matter what values are in the
45742
- cache or what arguments are used. A quick example - the following method will be cached,
45743
- only if the argument `name` has a length shorter then 32:
45742
+ cache or what arguments are used. A quick example - the following method will be cached
45743
+ only if the argument `name` has a length shorter than 32:
45744
45744
45745
45745
[source,java,indent=0]
45746
45746
[subs="verbatim,quotes"]
@@ -45769,7 +45769,7 @@ Each `SpEL` expression evaluates again a dedicated
45769
45769
<<expressions-language-ref,`context`>>. In addition to the build in parameters, the
45770
45770
framework provides dedicated caching related metadata such as the argument names. The
45771
45771
next table lists the items made available to the context so one can use them for key and
45772
- conditional(see next section) computations:
45772
+ conditional (see next section) computations:
45773
45773
45774
45774
[[cache-spel-context-tbl]]
45775
45775
.Cache SpEL available metadata
@@ -45847,7 +45847,7 @@ The cache abstraction allows not just population of a cache store but also evict
45847
45847
This process is useful for removing stale or unused data from the cache. Opposed to
45848
45848
`@Cacheable`, annotation `@CacheEvict` demarcates methods that perform cache
45849
45849
__eviction__, that is methods that act as triggers for removing data from the cache.
45850
- Just like its sibling, `@CacheEvict` requires one to specify one (or multiple) caches
45850
+ Just like its sibling, `@CacheEvict` requires specifying one (or multiple) caches
45851
45851
that are affected by the action, allows a key or a condition to be specified but in
45852
45852
addition, features an extra parameter `allEntries` which indicates whether a cache-wide
45853
45853
eviction needs to be performed rather then just an entry one (based on the key):
@@ -45876,7 +45876,7 @@ to the method outcome.
45876
45876
45877
45877
It is important to note that void methods can be used with `@CacheEvict` - as the
45878
45878
methods act as triggers, the return values are ignored (as they don't interact with the
45879
- cache) - this is not the case with `@Cacheable` which adds/update data into the cache
45879
+ cache) - this is not the case with `@Cacheable` which adds/updates data into the cache
45880
45880
and thus requires a result.
45881
45881
45882
45882
@@ -45887,7 +45887,7 @@ and thus requires a result.
45887
45887
There are cases when multiple annotations of the same type, such as `@CacheEvict` or
45888
45888
`@CachePut` need to be specified, for example because the condition or the key
45889
45889
expression is different between different caches. Unfortunately Java does not support
45890
- such declarations however there is a workaround - using a __enclosing__ annotation, in
45890
+ such declarations however there is a workaround - using an __enclosing__ annotation, in
45891
45891
this case, `@Caching`. `@Caching` allows multiple nested `@Cacheable`, `@CachePut` and
45892
45892
`@CacheEvict` to be used on the same method:
45893
45893
@@ -45903,7 +45903,7 @@ this case, `@Caching`. `@Caching` allows multiple nested `@Cacheable`, `@CachePu
45903
45903
[[cache-annotation-enable]]
45904
45904
==== Enable caching annotations
45905
45905
It is important to note that even though declaring the cache annotations does not
45906
- automatically triggers their actions - like many things in Spring, the feature has to be
45906
+ automatically trigger their actions - like many things in Spring, the feature has to be
45907
45907
declaratively enabled (which means if you ever suspect caching is to blame, you can
45908
45908
disable it by removing only one configuration line rather then all the annotations in
45909
45909
your code).
@@ -46207,7 +46207,7 @@ reference documentation].
46207
46207
==== Dealing with caches without a backing store
46208
46208
Sometimes when switching environments or doing testing, one might have cache
46209
46209
declarations without an actual backing cache configured. As this is an invalid
46210
- configuration, at runtime an exception will be through since the caching infrastructure
46210
+ configuration, at runtime an exception will be thrown since the caching infrastructure
46211
46211
is unable to find a suitable store. In situations like this, rather then removing the
46212
46212
cache declarations (which can prove tedious), one can wire in a simple, dummy cache that
46213
46213
performs no caching - that is, forces the cached methods to be executed every time:
0 commit comments