WebSphere 反向投资者: 解决 WebSphere Application Server 的配置冲突
简介： 任何时候，只要 IBM® WebSphere® Application Sever cell 有多个管理员，就会有管理操作相互冲突的可能性。WebSphere 反向投资者的这一期文章讨论了如何检测和解决相互冲突的配置更改。 本文来自于 IBM WebSphere Developer Technical Journal 中文版。
在每篇专栏文章中，WebSphere® 反向投资者将回答问题、提供指导并讨论与 WebSphere 产品使用相关的基础主题，经常会给出与流行的看法相悖的经过实践验证的建议。
配置疗法
让我先来向您解释一下，尽管我在本专栏的标题中使用了 “解决冲突” 的字样，但我并没有改变职业，而投身于调停或有关的行业。此外，虽然有关各种 WebSphere Application Server 主题的讨论可能会导致所谓的 “精神辩论”，但本专栏并不想涉及如何解决可导致这类辩论的观点的根本差异。相反，这里的焦点是如何检测和解决因并行更新 WebSphere Application Server 配置而产生的 WebSphere Application Server 配置冲突。
过去，我曾 写过一个专栏，这个专栏讨论了如何加速 WebSphere Application Server 内的应用程序部署，以避免在系统维护窗口期间进行并行应用程序部署的需求 — 而这会导致本专栏主题内所指的这类冲突。并且，在 上一篇 WebSphere 反向投资者 文章中，我推荐使用一个用于执行维护的双 cell 方法 — 软件和硬件 — 作为最小化甚至消除维护窗口中断的机制。我之前提到的两种方法仍然是在一个给定的时间框架内执行应用程序维护的建议方法，如果出于某种原因，您发现一个或两个或多个选项不适合您的具体环境，那么您可以将并行应用程序部署用作另外一个选项，具体步骤在本文中会给出。
在深入探究具体的过程之前，让我们先来简要讨论一下 WebSphere Application Server 提供的用于阻止配置冲突的嵌入功能。
每当有用户登录到一个管理员客户端（admin 控制台或 wsadmin）时，就会用一个不同的工作空间会话来跟踪变化。与每个工作空间相对应的是一个用于保存此用户接触过的所有文件的临时目录。此工作空间内的文件最初提取自 WebSphere Application Server 单元配置存储库并且此用户所做的所有更改都只反映在工作空间的副本，直到发生一次保存。当保存发生时，WebSphere Application Server 配置管理运行时会将来自此工作空间的已更改文件复制回这个主存储库，但首先会进行检查以确保已更改文件没有被另一个工作空间会话修改或保存过。只要两个工作空间会话修改了不同的文件，就不会有保存冲突。当有冲突时，只有第一个工作空间会话的更改会反映在 WebSphere Application Server 单元配置存储库中，而具有冲突文档的后续会话则会在保存期间收到一个保存冲突异常。在一个具有多用户的共享环境中，虽然总是可以读取这个配置，但是如果另一个工作空间会话试图保存已经由第一个工作空间修改的相同的文件时，那么保存这个工作空间会话可能不会成功。
对于应用程序部署，为了支持应用程序的并发部署，对其进行了一个特殊配置。由不同的工作空间会话初始化的应用程序部署可以修改相同的 serverindex.xml 文件，在这种情况下，WebSphere Application Server 配置管理运行时为 serverindex.xml 文件采用了一个合并算法，它支持：
- 向不同的应用程序服务器或不同的应用程序服务器群集并发部署不同的应用程序。
- 向相同的应用程序服务器或相同的应用程序服务器群集并发部署不同的应用程序。
结果，大多数典型的并发或并行应用程序部署场景都可安全执行，无需系统管理员方面的任何额外努力。不过，还有其他的应用程序部署场景（比如向相同的应用程序、相同的群集或服务器的并发部署，目前尚不能由 serverindex.xml 合并算法处理）以及其他的并发管理动作涉及的不只是应用程序部署，因此有可能发生配置冲突。有一些简单的措施可用来确保不会有配置冲突并为一些受支持的场景或在使用 wsadmin 时的其他一些场景解决所有冲突。
为配置冲突检测和解决所采用的 wsadmin 命令依赖于获得对 ConfigService MBean 的引用，然后调用由该 MBean 提供的 getConflictDocuments 方法来决定是否有相互冲突的变更发生自另一个管理会话。
获得所需对象引用以及构造此调用所需的参数列表的步骤如清单 1 所示。
清单 1
// get ConfigService MBean reference
wsadmin>cs = AdminControl.queryNames('WebSphere:*,type=ConfigService')
// obtain ObjectName for ConfigService MBean
wsadmin>import javax.management as mgmt
wsadmin>csName=mgmt.ObjectName(cs)
// get session object for the current administrative user session
wsadmin>session=AdminConfig.getCurrentSession()
// manipulate and prepare the administrative session object and
// MBean operation arguments for use
wsadmin>from com.ibm.websphere.management import Session
wsadmin>from jarray import array
wsadmin>parms=array([session], java.lang.Object)
wsadmin>ptype=array(['com.ibm.websphere.management.Session'], java.lang.String) |
如果您熟悉 MBean 方法的调用操作的使用，就会奇怪为何使用 invoke_jmx 操作而非调用。这是因为调用主要用来处理字符串且只能管理字符串的格式类型。为了使用标准 Java™ 类型数组和其他的非字符串，invoke_jmx 操作就提供了所需的函数。
在初始化变量和参数列表之后，就会调用 getConflictDocuments 方法。如果没有冲突，这个方法返回的结果将如清单 2 所示。否则，如果配置冲突的存在是因为在另一个管理会话中的更改，那么结果将会如清单 3 所示，它列出了更改了的 XML 文件。
清单 2
// invoke MBean getConflictDocuments method to obtain a list of any document conflicts
wsadmin>AdminControl.invoke_jmx(csName,'getConflictDocuments', parms, ptype)
{}
wsadmin> |
清单 3
wsadmin>AdminControl.invoke_jmx(csName,' getConflictDocuments', parms, ptype)
{['cells/ojaiCell01/nodes/ojaiNode01/serverindex.xml',cells/ojaiCell01/applications/
DefaultApplication.ear.ear/deltas/DefaultApplication.ear/delta-1278791909117',
... ...}
wsadmin> |
如果发生这种情况，就可以通过 AdminConfig.reset() 调用丢弃自上一次 AdminConfig.save() 调用后在会话内所做的更改：
wsadmin>AdminConfig.reset()
若在保存前调用 getConflictDocuments 方法后发现没有冲突文档，这并不能保证保存一定会成功 — 即便是被立即调用 — 因为其他的一些会话有可能在调用 getConflictDocuments 与进行实际的保存这段时间内修改了相同的文档。不过，如果向主存储库的保存不成功，那么就会出现一个 ConfigServiceException 异常，类似于在更新主存储库内的文档时出现的异常，如下所示：
WASX7015E: Exception running command: "AdminConfig.save()"; exception information: com.ibm.websphere.management.exception.ConfigServiceException java.security.PrivilegedActionException: java.security.PrivilegedActionException : com.ibm.ws.sm.workspace.WorkSpaceException: RepositoryException
如果发生这种情况，可以调用 getConflictDocuments 方法来决定哪些文档已经由其他会话保存。然后可以通过调用 AdminConfig.reset() 丢弃所做的更改。丢弃后，就可以重新应用您的修改。假设修改相同文件的并发程度并不很高（多少依赖一点运气），那么后续的重试应该会成功，没有冲突。
结束语
遵循这些步骤能够帮助您添加所需的函数来检测由部署多个并发管理动作可能引起的配置冲突，在需要的时候丢弃更新，进而避免配置冲突。
致谢
感谢 Ajay Apte、Michael Cheng、Amy Lin 和 Vish Venkataramappa 为本专栏的准备给予的协助。
原文链接：http://www.ibm.com/developerworks/cn/websphere/techjournal/1007_webcon/1007_webcon.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-675110/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-675110/