opmn跟jms实现toplink session缓存同步的解决方案

opmn和jms实现toplink session缓存同步的解决方案

在分布式应用中,单个业务应用的toplink运行在多个jvm上,同时开启了会话缓存,而这些在多个jvm上会话缓存中的domain对象就需要同步,这样可以及时拿到最新的信息而不需要每次都查询database,这大大减少了乐观锁冲突。在Oracle Application Server上Ormi端口是动态分配的,如果一个应用跑在多个jvm上,这些jvm的ormi服务端口也是不同的,所以在开发阶段无法确定这些信息,也不好采用多套toplink session的配置。庆幸的是opmn的request端口是固定的,我们可以使用opmn request端口来进行jndi的look up,然后用oc4j jms实现多jvm或者多OC4J instance之间toplink session缓存的同步, 因为经过测试OC4J in memory jms作为同步消息的传输和发现方式效率是最高的。
具体方法如下:

  1. 配置一个拥有 3 jvm oc4j instance

 


opmn跟jms实现toplink session缓存同步的解决方案

 

   2  toplink session cache 策略的配置

 


opmn跟jms实现toplink session缓存同步的解决方案

 

        <toplink:caching>
            <toplink:cache-invalidation-policy xsi:type="toplink:time-to-live-cache-invalidation-policy">
               <toplink:time-to-live>36000000</toplink:time-to-live>
            </toplink:cache-invalidation-policy>
         </toplink:caching>
 

 


 

3. 配置 JMS topic connection factory topic

 


opmn跟jms实现toplink session缓存同步的解决方案


opmn跟jms实现toplink session缓存同步的解决方案

 

具体每个配置参数代表什么意思,可参见 Oracle Containers for J2EE Services Guide

 

创建完毕后,在 instance level config 目录下面打开 jms.xml 可看见所作的配置更改:

       <topic
            name="cachesyn"
            location="jms/cachesyn"
        >
        </topic>


        <!-- unified connection factories -->


        <!-- queue   connection factories -->


        <!-- topic   connection factories -->
        <topic-connection-factory
            location="TopicConnectionFactory"
        />
 

 

 

 

4 opmn 配置

 

查看 opmn.xml, 获得 request 端口

<port local="6101" remote="6201" request="6004"/>

 

Opmn url 格式为: opmn:ormi:// 主机名 :opmn request 端口 :OC4J Instance Name /Application Name

 

 

5.配置toplink会话缓存同步策略


opmn跟jms实现toplink session缓存同步的解决方案

 

 

6. 权限设置

我们登录 console server 的全局用户,并不一定有 instance level rmi 等权限,所以不能实现 jndi lookup. Oc4j 默认采用的是基于文件的认证和授权管理策略,用的是 JAAS ,通常称为: jazn Oracle's authorization/policy provider for JAAS

打开全局的 j2ee/config/ system-jazn-data.xml 文件,元素 <jazn-policy> 有下面这一段, policy 主要就是为角色和用户分配具体权限的

<grantee>
            <principals>
                <principal>
                    <realm-name>jazn.com</realm-name>
                    <type>role</type>
                    <class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
                    <name>jazn.com/oc4j-administrators</name>
                </principal>
            </principals>
        </grantee>
 

 

 

只有 oc4j-administrators 角色才有这些权限。而 system team 分配给我们的用户并不拥有该角色,在 console 界面上也没找到为 server level 的用户也不能进行 oc4j-administrators 角色的交易,所以也没 jndi lookup 的权限,会报 javax.naming.AuthenticationException: Not authorized.

需要在 instance level 创建一个用户,用户名和密码和 server level 的相同或者也可以不同,然后为该用户分配权限,查看了一下 instance level system-jazn-data.xml 发现 jazn.com/ascontrol_admin jazn.com/oc4j-administrators 角色有完整 rmi 权限,内容如下:

 

    <permission>
                <class>com.evermind.server.rmi.RMIPermission</class>
                <name>login</name>
            </permission>
            <permission>
                <class>com.evermind.server.rmi.RMIPermission</class>
                <name>subject.propagation</name>
            </permission>
 

 

最简单的方法就是为该用户分配 jazn.com/ascontrol_admin 角色, jazn.com 可以省略因为 jazn.com 是默认域, oc4j 采用的是域,用户,角色,权限的层次授权策略。

 


opmn跟jms实现toplink session缓存同步的解决方案

 

 

当然我们也可以在 applciation level 做到最小权限控制,在 orion-application applciation level jazn-data.xml 中进行设置和分配。具体方法可参见

Oracle® Containers for J2EE Security Guide

http://download-east.oracle.com/docs/cd/B25221_04/web.1013/b14429/toc.htm

 

7.Deploy 应用到 application server

这下可以享受 toplink cluster 带来的高性能的乐趣了。

如果成功的话:我们可以看到 oc4j_instance jvm1 toplink 有如下的 log

[TopLink Finest]: 2008.12.03 06:58:30.961--ServerSession(24138346)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Retreived remote message from JMS topic: cachesyn
[TopLink Finest]: 2008.12.03 06:58:31.020--ServerSession(24138346)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Received remote command oracle.toplink.remotecommand.MergeChangeSetCommand from Service[TopLinkCommandChannel, 3673206, opmn:ormi://localhost:6004:OC4J_TTS/tts]
[TopLink Finest]: 2008.12.03 06:58:31.023--ServerSession(24138346)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Executing command oracle.toplink.remotecommand.MergeChangeSetCommand from Service[TopLinkCommandChannel, 3673206, opmn:ormi://localhost:6004:OC4J_TTS/tts]
[TopLink Finer]: 2008.12.03 06:58:31.098--ServerSession(24138346)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Received updates from Remote Server
[TopLink Finest]: 2008.12.03 06:58:31.110--ServerSession(24138346)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Merging com.ldd600.isdc.sha.frm.tts.model.Employee: [22] from remote server

 

Oc4j_instance jvm2 toplink 有如下的 log

 

[TopLink Finest]: 2008.12.03 06:58:30.721--ServerSession(8762565)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Received remote command oracle.toplink.remotecommand.MergeChangeSetCommand from Service[TopLinkCommandChannel, 3673206, opmn:ormi://localhost:6004:OC4J_TTS/tts]
[TopLink Finest]: 2008.12.03 06:58:30.724--ServerSession(8762565)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Executing command oracle.toplink.remotecommand.MergeChangeSetCommand from Service[TopLinkCommandChannel, 3673206, opmn:ormi://localhost:6004:OC4J_TTS/tts]
[TopLink Finer]: 2008.12.03 06:58:30.734--ServerSession(8762565)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Received updates from Remote Server
[TopLink Finest]: 2008.12.03 06:58:30.736--ServerSession(8762565)--Thread(Thread[RMICallHandler-5,5,HTTPThreadGroup])--Merging com.ldd600.isdc.sha.frm.tts.model.Employee: [22] from remote server