dev2dev 首页 > 资源中心 > 技术文章
事务管理----WebLogic 服务器系统管理
为什么应用服务器这么令人厌烦？我看这个问题的答案要依赖于你的看法。某人的生活日用品可能是另一个人的必须品。那样单独地观察可能会产生相当短的专栏，因此，我们需要问另一个问题，到底这些人是谁？
应用服务器通常是从一个应用开发者的观点来观察。毕竟，J2EE是一套有趣的，深厚的规范；他们对于那些有着开发信念的人非常有吸引力，并且如果你能在摘要中正确地拼写首字母缩写得话，它看起来还不错。总而言之，一点也不令人厌烦，并且还是一个必需品，但是情况并不总是这样。
应用服务器的出现反应了软件工程作为一个学科越来越趋于成熟，就像它从一种严格的技术转变成为一种科学。不管这些成熟过程，当我偶遇一些仍然在为编写他们自己的应用结构而高兴的开发者时，我感到很吃惊。"不是为了我的管理环境的straightjacket！"他们喊道，愉快的从他们的容器中取出线程池库并且将其嵌入到下一部软件著作中。这些行为使我想起了《Round
Ireland With a Fridge 》，这本书勇敢的作者坐在冰箱中环绕爱尔兰。它带来了非常有趣的旅行写作，但是我不指望冰箱运输的构想成为曾经考虑过的最有效的机制。
很多的应用程序开发者也发现系统管理令人厌烦。毕竟，它是整个应用生命周期中乏味的一部分；令人兴奋的、有创造性的部分已经结束，余下的所有要做的就是坐着等待红灯闪亮，然后重新启动服务器。这是多么无聊的事呀？
虽然它是一个反问，但也值得回答。如果你对一个应用程序拥有预算，那么它的生命周期的运作一点也不无聊。牢牢记住一个有用的应用程序可能有着超过10年以上的产品寿命。现在，将它与发展周期相比较，在应用集成和组件重用这些日子里，典型的是在六个月或更少的时间内完成。设想在这段期间你每天存1
美元……现在还厌烦什么吗？如果我可以把这些存款据为己有，我将得到10年的操作寿命，3650美元――发展周期几乎一点也不有趣。
这些经验使聪明的用户注意到软件产品系列的许可价格，并且转移他们的注意力到解决方案整个部署生命周期的所有权的总成本上。这也使得那些成熟的软件工程师抛弃他们专用的线程管理库并花费长期的，困难的考虑在应用服务器上。为什么呢？所有runtime引擎的定制组件都是另一个基础组件的一部分，这部分组件需要被考虑并在部署中由一个在其特性方面受过训练的人来提供。它对于进行部署的组织很不利，如果他们不高兴的领导在休假或更遭，从公共汽车上掉了下来，怎么办？这对领导也很不好。所有这些他们不得不积累的知识都是不可转让的，因此，在他们所喜欢的机房之外或远离心爱的公司pager（大概是一个铭记的金色pager，因为他们已经在那里如此长的时间）的事业前景被限制。他们是应用服务器管理员该多好（或是WebLogic应用服务器管理员会更好）？
这与事务有什么关系？这是关于事务两段式提交和ACID（如果你非常赞同的话）非常有吸引力的见解，但是在一天结束时，事务要处理有价值的商业数据的完整性。大部分操作人员忽视的是失败了的有价值的商业数据。由于这个原因，他们需要工具来监控正发生的事情，以确保所有事务是健壮的，如果最坏的情况发生，当事情开始在产品上失败时来完成事务，因此他们能使系统依靠轨迹以最小限度的忙乱和数据丢失进行恢复。
WebLogic Server提供了什么工具使系统管理员可以看到发生了什么以及在发生故障后进行恢复？WebLogic
Server关于事务提供了什么样的管理能力？让我们暂停，先看看专业的WebLogic Server管理员处于什么样的处境。
服务器管理员
我总是在想在任何分布式系统中，不言而喻的事务记录和恢复服务都应是分布式的。显然不是这样的，然而，WebLogic
Server的主要竞争者之一集中在一个提供了相当古怪的单一失败点的中央管理服务器的事务日志上。保证休息，在WebLogic
Server中没有这么虚弱的设计者，因此首先要调整处理管理分布式事务日志的能力。所有运行JTA系统的服务器实例都有它们自己的一套事务日志。通常，当它们不再是当前使用的时候会被服务器清除，但是如果服务器失败，决定事务（写在事务日志中的）需要向前回滚。如果相关联的WebLogic
Server实例重新启动，这个过程是自动进行的；如果这样不行，那么记录下来的事务需要通过集群中的另外一个成员进行恢复。从失败的服务器到备份服务器进行转移事务恢复服务。为了达到恢复的目的，日志文件必须对于备份服务器可视化（它们通过恢复过程处理），因此双端口磁盘，SAN，或其他这样的技术必须被放在适当的位置。当原来的服务器被重新启动时，恢复服务将会返回到原来的地方，如果恢复完成的话。
如果对于自动恢复来说失败非常严重的话（数据库崩溃，机箱起火等），一个未被记载的应用将以一种易读的形式转储事务日志的内容。它可以在为严重问题的分析上证明其价值，并且其细节可以通过BEA的支持获得。
这个专栏的长期读者现在可能确信对于盲信的人适用heuristically完整的事务。对于这些人，在管理员工具包中有两样好东西。第一个是，管理员可以设置一个事务放弃的超时时间。如果事务不能在这个时间限制之前完成（可能由于数据库不存在），服务器将放弃尝试。因为现在数据可能不一致，已经发生了我们喜欢的试探结果之一。但是往好处看，服务器没有浪费无限的精力进行不可能的操作。当然对于所有这些情况，服务器将会写进日志记录来记录失败。
第二个可能发生的被记录下来的heuristic结果在heuristic日志中。如果服务器已经从外部事务管理器（例如，通过
IIOP 的OTS）引入了一个事务，服务器本身的行为更像一个XA资源。这给了它在罕见的灾难性情况中（例如，在事务放弃超时期限之后或在WebLogic
Server 中共享的XA资源引入的事务抛出了heuristic例外）做heuristic决定的权利。简而言之，事务会向前或向后单向滚动，不管有没有外部事务管理器的允许。当这些情况发生时，事件被记录在heuristic日志文件中。它们共存于一个tlog文件，在.tlog扩展名之前文件名中有一个.heur。当在非常复杂的部署中发生错误时我们要查看这个文件。（我劝你在stiff
drink之后只看这些文件――在这种情况中，你可能会用一整夜！）
在少数紧急时期，管理员可以当事务通过系统时监控他们。很明显的，由于事务应该持续时间很短，它将是或应该是系统状况的一个ever-changing
快照。管理员可以提前得到即将发生故障的警报的一种途径是，事务启动花了很长时间来完成。由于这个原因，通过这些事务的有效时间，对所显示的使用中的事务进行排序是有可能的。应用程序开发者关于在正常情况下应该运转什么样的事情，需要给管理员一个指导方针，但是很多持续很长时间的事务突然出现的话可能是一个大故障的提前预兆。
当我们谈论开发者和操作员之间交流的必要性时，我们应该回顾一些特征。WebLogic Server承认和每个事务相关联的名字；它可以通过weblogic.transaction事务接口或对于容器管理的事务来说通过EJB容器自动的programmatically完成。当管理员正着眼于使用中的事务或一个转储的事务日志时，了解到商业操作在事务范围内正在被尝试（开发者：给他们有意义的名字！）它可以给故障的研究一个很好的起点。例如，计算转移事务将接触到两个数据库，更新地址细节将访问客户的数据库，等等。
WebLogic Server管理员也可以在服务器中设置限制：并发事务的最大允许数，默认的事务超时时间，放弃超时时间，等等。通常在应用服务器配置中，特别是在JTA中，用这些限制来控制应用服务器将承担的工作数量是非常重要的。牢牢记住在任何给定的硬件中部署，对于可能的吞吐量将有一个物理上的限制。通过使用管理上的控制来阻止应用服务器试图超过这个物理极限，当所有的事情由于缺乏继续运行的硬件资源而随便的中断时，你可以确保当它从极限操作平息下来时你的部署只是使少数的用户失望，而不是使所有的用户都失望。
总结
唉……我筋疲力尽了！我感觉就像快速短跑穿过一座信息的山丘一样。不可避免的，管理的技术和细微差别对于任何给定的应用都超过了单一的，相对不足的，普通的column的范围，但是我希望它可以提供设备可用的一种调剂，并且可以给你指出哪里可以得到更多的信息。
最后，我想确认它是真实的。如果管理是令人厌烦的，那么应用服务器也是令人厌烦的（WebLogic
Server就是更让人厌烦了）因为当应用服务器向开发者提出好的期望，当他们参与最擅长的后台工作，
providing years of trouble，自由操作他们所支持的系统时，会认识到其实际的价值。
参考
· Hawks, Tony.(2000). Round Ireland With a Fridge.
St. Martin's Press.
· The WebLogic Server JTA Administration Guide:
http://edocs.bea.com/wls/docs70/adminguide/mamagetx.html
| 作者简介 |
|
Peter Holditch 是英国的一名资深售前工程师，他为Azul Systems公司工作。加入Azul之前，他在BEA systems工作了九年，起初是BEA在欧洲的第一批专业服务顾问之一，离开时他已经成为资深的售前工程师。他拥有研发背景（最初曾致力于BEA的Tuxedo产品），在技术方面的主要兴趣是高吞吐量事务系统。工作之余，Peter喜欢自酿啤酒、做家具或进行其他有趣且具有挑战性的工程——但是（一般）不会同时进行！ |
作者其它文章
|
