Java Reference
In-Depth Information
The first thing we want to stress on is the @Resource annotation, which injects an
EmbeddedCacheManager instance. When the WildFly deployer encounters this an-
notation, your application will include a dependency on the requested cache container.
Consequently, the cache container will automatically start during deployment and stop
(including all caches) during undeployment of your application.
Subsequently, when the EJB is instantiated (see the method start , which is annotated as
@PostConstruct ), org.infinispan.Cache is created using Embed-
dedCacheManager as a factory. This cache will be used to store our highly available
set of data.
The operations performed against the distributed cache are quite intuitive: the put meth-
od is used to store instances of the Seat object in the cache and the corresponding get
method is used to retrieve elements from it, just what you would do using an ordinary
hashmap. The only difference is that in our clustered cache, every entry must be serializ-
able. Be sure to mark Seat as Serializable and create a default constructor for it.
As far as application deployment is concerned, you need to state a dependency to the In-
finispan API explicitly, which is not included as an implicit dependency in WildFly's
class-loading policy. This is most easily done by adding the following line to your applic-
Dependencies: org.infinispan export
We additionally need to add the new cache container to the appropriate profile in our do-
main.xml file (in the Infinispan subsystem):
<cache-container name="tickets" default-cache="default"
<transport lock-timeout="60000"/>
<replicated-cache name="default" batching="true"
<locking isolation="REPEATABLE_READ"/>
Search WWH ::

Custom Search