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

最新推荐文章于 2019-06-08 09:17:49 发布

hongrenldd

最新推荐文章于 2019-06-08 09:17:49 发布

阅读量213

点赞数

分类专栏： Java Persistence JPA JDO; Transaction JTS JTA and ORM 文章标签： JMS Oracle thread JVM 配置管理

Java Persistence 同时被 3 个专栏收录

4 篇文章 0 订阅

订阅专栏

JPA

4 篇文章 0 订阅

订阅专栏

JDO; Transaction

4 篇文章 0 订阅

订阅专栏

在分布式应用中，单个业务应用的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作为同步消息的传输和发现方式效率是最高的。
具体方法如下：

配置一个拥有 3个 jvm的 oc4j instance

2 toplink session cache 策略的配置

        <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

具体每个配置参数代表什么意思，可参见 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 端口

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

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

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 采用的是域，用户，角色，权限的层次授权策略。

当然我们也可以在 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