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-
ation's
META-INF/MANIFEST.MF
:
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"
jndi-name="java:jboss/infinispan/tickets"
module="deployment.ticket-agency-cluster.jar">
<transport lock-timeout="60000"/>
<replicated-cache name="default" batching="true"
mode="SYNC">
<locking isolation="REPEATABLE_READ"/>
</replicated-cache>
</cache-container>
