abstract
This section deeper into the Introduction of the JBoss Cache architecture, it is applicable to the use of higher desired level cache function, enhanced or expanded cache, write compiled plug or a bottom layer solution running machine the use of the system.
JBossCache in the data structure
JBossCache collection Composition Examples by the Node tree-type structure of the tissue. Each of which contains a Node saved to the cache data object table. Note that, a structure which is a kind of mathematical trees, and non-graphics; are each one and only Node We have a parent node, and the root node is represented by an invariant Fqn.ROOT fully qualified name table.
On the surface of the table in FIG., Each block represents both a JVM. You can see the two cache located in a different JVM, the data is copied to each other. Wherein any of a cache in any of the modifications are copied to a cache Further in . Since then, the cluster system can have multiple cache. According to the transactional root set, or copying the end of transaction after each modification occurs (when submitted) into the line. When a new cache is created, it can obtain a two existing cache at startup content.
SPI Interface
In addition to Cache and Node interfaces, JBossCache also open more powerful and NodeSPI of CacheSPI interface, they provide for internal JBossCache more and more control. These interfaces are not used for ordinary uses, which are applicable to expansion and increase of JBossCache, ed write custom interceptor (Interceptor) or a class loader (the CacheLoader) instance.
CacheSPI interface can not be created, but it relies on these interfaces setCache (CacheSPI cache) method injected into Interceptor and CacheLoader achieving in. CacheSPI inherits Cache, as to the basic API functions are all available. Similar to, NodeSPI interface also can not be created. Instead, it is performed through the operation to obtain the CacheSPI. For example, Cache.getRoot (): Node is covered as CacheSPI.getRoot (): NodeSPI.
Note that both natural interface inheritance is not able to guarantee to maintain the contracts before, we not recommended direct conversion Cache or Node to its corresponding SPI interface, which is not good for practices. From a further aspect to say the outer, open public API is used to maintain guaranteed to be.
Method call on the node
既然缓存基本上是一个节点的集合,当作为整体或单个节点调用缓存上的操作时,集群、持久化、逐出等方面都需要应用到这些节点上。要以一种清洁、模块化和可扩展的方式实现这一点,我们使用了一种拦截器链。这个链由一系列的拦截器组成,每个都添加了一种方面或特定的功能。当缓存创建时,这个链将基于所用的配置构建。
请注意,NodeSPI 提供一些直接在节点上操作而无需通过拦截器链的方法(如 xxxDirect() 方法族)。插件作者应该注意到使用这样的方法将影响到缓存可能需要应用的方面,如锁、复制等。为简便起见,请不要使用这些方法,除非你真的知道自己在干什么。
拦截器
JBossCache 基本上是一个核心的数据结构 - 对 DataContainer 的实现 - 方面和功能在此数据结构之上用拦截器实现。CommandInterceptor 是一个抽象类,拦截器实现继承了它。CommandInterceptor 实现了 Visitor 接口,所以它能够以一种强类型的方式修改命令。下节将介绍关于 Visitor 和 Command 的更多内容。拦截器实现在 InterceptorChain 类里被链接在一起,它在整个链里分发一个命令。CallInterceptor 是一个特殊的拦截器,它总是位于链的末端来调用通过 process() 方法传递的命令。JBossCache 附带几个拦截器,代表着不同的行为方面,例如:
- TxInterceptor - 查找正在进行的事务并注册事务管理者以参与同步事件
- ReplicationInterceptor - 用 RpcManager 类在群集里复制状态
- CacheLoaderInterceptor - 如果内存里没有请求的数据时,从持久性存储加载数据
针对你的缓存实例配置的拦截器链可以通过调用 CacheSPI.getInterceptorChain() 获得和检查,这个方法返回一个已排序的拦截器List,它是以命令将遇到的顺序进行排序的。
当然我们也可以编写自定义的拦截器,通过继承CommandInterceptor 并基于你感兴趣拦截的命令来覆盖相关的 visitXXX() 方法,你可以编写自定义的拦截器以添加特殊的方面或功能。你也可以继承一些其他的抽象拦截器,如PrePostProcessingCommandInterceptor和SkipCheckChainedInterceptor。关于其他功能的细节,请参考相关的 Javadoc。自定义拦截器需要使用Cache.addInterceptor() 方法添加到拦截器链中。JBossCache 也支持通过XML 配置自定义拦截器。
Command 和 Visitor
JBossCache 在内部使用一种command/visitor 模式来执行 API 类。每当在缓存接口上调用一个方法,实现了 Cache 接口的CacheInvocationDelegate 将创建一个 VisitableCommand 实例并将这个命令分发到拦截器链里。而实现了Visitor 接口的拦截器能够处理它们所感兴趣的 VisitableCommand 并添加行为到这个命令里。
每个命令都包含了正在执行的命令的全部知识,如所使用的参数和封装在process() 方法里的处理行为。例如,当调用 Cache.removeNode() 时,RemoveNodeCommand 将被创建并传递到拦截器链里,而 RemoveNodeCommand.process() 知道如何从数据结构里删除节点。
除了可被访问以外,命令也是可以复制的。JBossCache marshaller 知道如何高效地将命令编码并使用内部的基于 JGroups 的RPC 机制在远程缓存实例上调用它们。
InvocationContexts
InvocationContext保留着单次调用期间的中间状态,且由位于拦截器链前端的 InvocationContextInterceptor 设置和销毁。InvocationContext,顾名思义,持有和单次方法调用相关联的上下文信息。上下文信息包含相关联的 javax.transaction.Transaction 或 org.jboss.cache.transaction.GlobalTransaction、方法调用起始者(InvocationContext.isOriginLocal())、以及被锁定的节点相关的信息等。InvocationContext 可以通过调用 Cache.getInvocationContext() 获取。
用于子系统的管理者
有些方面和功能是由多个拦截器共享的。其中一些已经封装成管理者,由不同的拦截器所使用,且通过 CacheSPI 接口被访问。
- RpcManager - 这个类负责通过 JGroups通道的对远程缓存的 RPC 调用,它封装了所使用的 JGroups 通道
- BuddyManager - 这个类管理 Buddy 组并调用组远程调用以将缓存群集组织为更小的子组
- CacheLoaderManager - 设立和配置缓存加载器。这个类在委托类里包裹了单独的 CacheLoader 实例, 如 SingletonStoreCacheLoader 或 AsyncCacheLoader,或者用 ChainingCacheLoader 在链里添加 CacheLoader
编码(Marshalling) 和线格式(Wire Format)
JBossCache 的早期版本只是简单地通过 ObjectOutputStream 在复制时将缓存数据写入到网络里。在JBoss Cache 1.x.x 系列的几个版本里,这种方法逐渐被取消而采用了一种更为成熟的编码框架。在 JBoss Cache 2.x.x 系列里,这是官方支持和推荐的写入对象到数据流里的唯一机制。
Marshaller接口从 JGroups 继承了RpcDispatcher.Marshaller。这个接口有两个主要的实现- 委托的 VersionAwareMarshaller 和具体的 CacheMarshaller300。 通过调用 CacheSPI.getMarshaller() 可获得 marshaller,缺省是 VersionAwareMarshaller。用户也可以通过实现 Marshaller 接口或继承 AbstractMarshaller 类编写自己的 marshaller,并通过Configuration.setMarshallerClass() setter 将其添加到配置中。
VersionAwareMarshaller, 顾名思义,这个 marshaller 在写入时添加版本 short 到任何流里,启用相似的VersionAwareMarshaller 实例来读取版本short 并知道哪个专有的 marshaller 实现来委托调用。例如, CacheMarshaller200 是用于 JBoss Cache 2.0.x 的 marshaller。JBoss Cache 3.0.x 附带具有改进的 wire 协议的CacheMarshaller300。使用 VersionAwareMarshaller 帮助实现次要版本间的 wire 协议的兼容性,但仍然让我们可以灵活地调整和改进次要和micro 版本间的 wire 协议。
类加载和区
When used in the server should be used when the cluster state, the deployed Applications tends to be designed to there are examples of objects put into the complex required to be made in the cache (or objects are HttpSession). To be made by each deployment server ClassLoader instance allocated independent of Applications in but by the ClassLoader application servers to JBoss Cache libraries referenced, it is very often see.
To successfully loaded from the class pair object encoding and decoding, we use the one called Almost region (region) is read. A zone is a part of the cache, which share a well-used class loader (which he has regions Uses - see next eviction (eviction) introduction).
Area is through the call Cache.getRegion (Fqn fqn, booleancreateIfNotExists) method and return the Region to achieve the interfaces created . Obtained in the region, the region class loader may set or cancel the setting, the region may activate and to cancel activation. In the default case, a region of activity, unless InactiveOnStartup configuration attribute is set to true.
Reproduced in: https: //my.oschina.net/iwuyang/blog/197193