事务：在控制之中吗？--附一些高深内容

　　BEA的WebLogic Platform 8.1的发布引起了行业分析家和IT从业者的极大热情，他们认识到它的潜力使J2EE平台的强大功能为更多的开发人员所使用。  这使得J2EE架构师可以做它最擅长的工作--体系设计和技术问题的解决，同时允许"普通"开发人员使用由专家设计的体系结构，这些开发人员迄今为止还被限制于构建部门级的应用程序，因为他们缺少体系结构，从而缺乏可伸缩性来支持过去常使用的易用工具来生成的应用程序。
WebLogic Platform的两个关键特征可以把高级业务开发人员和高级J2EE架构师的职责分开--BEA WebLogic Workshop的运行时（runtime），它利用高级体系结构命令对资深业务人员施加影响；Workshop开发环境，它允许开发者通过一致的图形抽象与环境相互作用，只有在需要表达业务规则而不是组装应用程序时才转变为代码行。IDE同样有帮助架构师的特性--它们可以产生骨架式的应用程序环境，植入标准组件等，并可以把这一环境以模板的形式向其他开发者发布，这使得业务程序员可以通过预先打包的方式和自动的方式快速启动工程（重要的是，这是一个与开发标准及其他开发工程一致的快速启动）。
从总体上来说，以J2EE开发者的角度来看，他们开始尽量避免做沉闷的、易错的剪切和粘贴工作--让我们做这些工作吧，它只不过是形成前端的另一个struts，或者只不过是另一个代码摘录来在JNDI查找JMS队列并通过它发送消息，没有人愿意干这种事。从非J2EE开发者的角度来说，用之前存在的组件组装有用的应用程序（比如以一种新的方法组合现有子系统的另一套Web页面）就变为可能，而这并不需要通过挑灯夜战来学习J2EE知识。
事务：您失去了计划吗？

控件只是简单的有注释的Java对象--这些注释提供了允许控件用户在高于通常的J2EE接口的抽象级工作的能力。当部署控件（实际上可能是多个控件的组合）时，注释对生成运行时联结（它是真正被部署的部分）起推动作用。与其他任何Java对象一样，控件从调用者中继承了事务上下文。因为控件没有远程接口的概念（至少当前的版本没有），所以调用者通常是由包含在EJB中的WebLogic Workshop生成的轻重量级控件容器。如果您查看与这个（WebLogic Workshop管理的）EJB关联的部署描述符，就会看到它有"容器"的事务策略--这样控件的事务上下文可以由EJB容器使用JTA提供，就像该控件是您编写的并从EJB代码调用的简单陈旧的Java对象。

当对Web服务方法进行调用时，从消息到达调用的联接已经通过大量J2EE（这完全取决于您在注释里的声明）机制完成，最后到达具有容器管理事务的EJB中。在执行方法期间， JTA事务将会运行。
回忆这一点，即使WebLogic Workshop Web服务是可会话的（如果注释是这么说）。会话状态保存在数据库的表中，这一持久状态是如何与任何应用程序管理的持久状态关联的呢？它们包含在同一事务的上下文中。这样如果您的方法失败了，就好像这段会话从来没有发生过。精细自动的行为事务是受的。这对部署意味着，在默认情况下，对话状态通过cgDataSource数据源保存。如果您的应用程序状态保存在别的地方，您可能会得到错误提示：不能通过事务影响数据源，因为它已经影响了作为cgDataSource底层的cgPool。您可以通过两种方法来修正该错误：要么更改cgPool来使用xa的数据库访问并得到两阶段的提交，要么让会话状态和应用程序状态通过相同的连接池保留在同一数据库实例中（Workshop的jws-config.properties文件从WorkShop角度进行控制）来避免两阶段的提交需要。
当然，现在应用的是事务的通常规则。如果您想保存一些数据（比如审计记录）而不考虑事务最终的结果，则您需要用到TransactionManager对象，在调用之前挂起事务，并在稍后进行恢复。对非J2EE的高手来说这是很常见的，因为这会使该对象成为J2EE架构设计师应该实现并提供给应用程序开发人员作为预先构建的控件。
关键是，它没关系！