MB中消息流事务.docVIP

Message flow transactions 文章位置：WebSphere Message Broker Version Developing message flow applications Processing messages Message flow behavior Default behavior Message flow transactions MB支持事务并且消息流处理的所有消息都有一致的事务。一个消息流事务从input节点接收到输入信息开始，到这个消息处理完成事务提交，如果出错事务会回滚。 如果消息流包含多个input节点，每个节点收到消息后都会重启一个事务。MB会对每种输入节点启动一个事务，包括用户自定义的。 如果一个系统支持自己的事务如数据库，你可以把这个事务配置到流事务中。基于这个节点，即可以当在这个系统中工作完成之后立即在该系统中提交事务，也可以或者在消息流事务完成时，提交事务。 许多在消息流中可使用的资源例如数据库、MQ消息、队列、JMS消息，都被资源管理器控制着，这个资源管理器就是用来协调事务的。其他的资源管理器不提供事务，如：HTTP协议和文件系统。 Commit or rollback 如果资源支持事务，你可以对着这资源进行配置，只有当消息流结束或者节点结束猜提交或回滚事务。数据库和WMQ队列就是典型的这样的资源。如果资源不支持事务，那么对该资源的所有操作会立即提交。例如文件和HTTP连接。 当消息流成功处理完成输入的消息的时候，所有的更新会立即被提交。遇到一下两种情况时，操作会被回滚： ·除了输入节点之外，流中的某个节点抛出异常却没被相应节点捕获（如节点本身或TryCatch节点） ·输入节点的捕获终端没有连接上 在分布式系统中，消息流的事务默认是由broker管理的。这些事务叫做broker-coordinated transactions或者partially coordinated transactions。When control returns to the input node when the flow finishes processing, the node either commits or rolls back the operations that have been taken, excluding the individual nodes that have been configured to perform their own commits and rollbacks, or that have no support for this option. 如果消息流同时访问多个资源，其中有一个发生了错误，所有个资源的操作都不会提交。 如果数据或操作的一致性要求很高，即所有操作要么提交要么回滚，你可以协调消息流活动来实现。协调是通过另外一个事务管理器提供的，它使用的XA协议。当消息流结束的时候由输入节点调用事务管理器。事务管理器（不是输入节点和代理）协调相关资源管理器，来为每个资源创建合适的动作。这种方式的事务控制，叫做globally coordinated transactions。 事务总是全局一致的，这个无需配置。 The role of the transaction manager 如果消息流中的所有操作都成功了，那么这些操作对于部分和全局一致性的事务是没有任何区别的。全局一致性事务的优点就是所有操作，要么全部提交，要么全部回滚。 执行阶段性提交策略的事务控制器，在其他资源控制器暂时不可用的时候也可以工作。这种潜在的小范围的失败对于你的环境来说可能是耗费巨大的，这个额外的事务控制器能帮助消除这些偶然发生的错误情况。因此，是否需要一个额外的性能消耗的事务控制器，取决于设计者的决定，而不是有消息流设计时决定。 即使是使用了事务一致性，一个额外的事务控制器也并不能阻止消息的丢失。所以，需要尽量多的配置并编写消息流来处理可能的错误。 要配置一个消息流是有全局事务控制的，你必须配置你的环境，使这个资源管理器支持事务控制。 On distributed systems, transactions can be coordinated by WebSphere?MQ On z/OS, all transactions are globally coordinated by Resource Recovery Service (RRS) 这些配置可能需要同时配置事务控制器和资源管理器。 Database access modes and locks 当所有操作针对同一个数据的时候，而在一个消息流中又存在一个是自动事务和另一个是提交事务事务的节点