Interface EntryProcessor<K,V,T>
- Type Parameters:
K
- the type of keys maintained by this cacheV
- the type of cached valuesT
- the type of the return value
Cache.Entry
atomically, according to the defined
consistency of a Cache
.
Any Cache.Entry
mutations will not take effect until after
the process(MutableEntry, Object...)
method has completed
execution.
If an exception is thrown by an EntryProcessor
, a Caching Implementation
must wrap any Exception
thrown wrapped in an EntryProcessorException
. If this occurs no mutations will be made to the
Cache.Entry
.
Implementations may execute EntryProcessor
s in situ, thus avoiding
locking, round-trips and expensive network transfers.
Effect of MutableEntry
operations
Cache.Entry
access, via a call to
Cache.Entry.getValue()
, will behave as if
Cache.get(Object)
was called for the key. This includes updating
necessary statistics, consulting the configured ExpiryPolicy
and loading
from a configured CacheLoader
.
Cache.Entry
mutation, via a call to
MutableEntry.setValue(Object)
, will behave as if Cache.put(Object, Object)
was called for the key. This includes updating
necessary statistics, consulting the configured ExpiryPolicy
, notifying CacheEntryListener
s and writing to a
configured CacheWriter
.
Cache.Entry
removal, via a call to
MutableEntry.remove()
, will behave as if Cache.remove(Object)
was called for the key. This includes updating necessary statistics, notifying
CacheEntryListener
s and causing a delete on a configured
CacheWriter
.
As implementations may choose to execute EntryProcessor
s remotely,
EntryProcessor
s, together with specified parameters and return
values, may be required to implement Serializable
.
Effect of multiple MutableEntry
operations performed by one EntryProcessor
Only the net effect of multiple operations has visibility outside of the Entry
Processor. The entry is locked by the entry processor for the entire scope
of the entry processor, so intermediate effects are not visible.
Example 1
In this example, anEntryProcessor
calls:
MutableEntry.getValue()
MutableEntry.setValue(Object)
MutableEntry.getValue()
MutableEntry.setValue(Object)
Cache
effects:
Final value of the cache: last setValue
Statistics: one get and one put as the second get and the first put are internal to the EntryProcessor.
Listeners: second put will cause either a put or an update depending on whether there was an initial value for the entry.
CacheLoader: Invoked by the first get only if the entry is not present, a loader was registered and read through is enabled.
CacheWriter: Invoked by the second put only as the first put was internal to the Entry Processor.
ExpiryPolicy: The first get and the second put only are visible to the ExpiryPolicy.
Example 2
In this example, anEntryProcessor
calls:
MutableEntry.getValue()
MutableEntry.remove()
}MutableEntry.getValue()
MutableEntry.setValue(Object)
Cache
effects:
Final value of the cache: last setValue
Statistics: one get and one put as the second get and the first put are internal to the EntryProcessor.
Listeners: second put will cause either a put or an update depending on whether there was an initial value for the entry.
CacheLoader: Invoked by the first get only if the entry is not present, a loader was registered and read through is enabled.
CacheWriter: Invoked by the second put only as the first put was internal to the Entry Processor.
ExpiryPolicy: The first get and the second put only are visible to the ExpiryPolicy.
Example 3
In this example, anEntryProcessor
calls:
MutableEntry.getValue()
MutableEntry.setValue(Object)
}MutableEntry.getValue()
MutableEntry.setValue(Object)
MutableEntry.remove()
Cache
effects:
Final value of the cache: the entry is removed if it was present
Statistics: one get and one remove as the second get and the two puts are internal to the EntryProcessor.
Listeners: remove if there was initial value in the cache, otherwise no listener invoked.
CacheLoader: Invoked by the first get only if the entry is not present, a loader was registered and read through is enabled.
CacheWriter: Invoked by the remove only as the two puts are internal to the Entry Processor, provided that the first #getValue was non-null.
ExpiryPolicy: The first get only is visible to the ExpiryPolicy. There is no remove event in ExpiryPolicy.
- Since:
- 1.0
-
Method Summary
-
Method Details
-
process
Process an entry.- Parameters:
entry
- the entryarguments
- a number of arguments to the process.- Returns:
- the user-defined result of the processing, if any.
- Throws:
EntryProcessorException
- if there is a failure in entry processing.
-