ejb的事务与实体bean

         应该使用声明方式控制事务还是使用编程方式控制事务？
事务与实体Bean（事务类型Bean、Container)<transaction-type>Bean/Container</transaction-type>
首先不要误解事务和实体Bean的关系。
EJB组件有两种划分事务边界的方法-------编程型和声明型。
编程型事务
   大多数现有的系统都是用编程型来划分事务边界。当使用了这种方法时，您必须将事务的逻辑操作编入您的应
用程序代码中。也就是说，您必须负责发布一个事务开始的声明和一个提交或异常结束的声明。例如：一个EJB的
银行应用系统程序必须要有一个EJB组件来充当银行出纳员，该出纳员Bean将实现银行帐号的转帐过程。按照编程
型事务，出纳员Bean负责发布一个事务开始的声明，执行资金的转帐，然后发布一个提交或异常结束的声明。这是
一种传统的事务执行模式（精通EJB P236)

声明型事务
  声明型事务允许组件自动的参与到事务中去。总而言之，您的EJB组件不会发布事务开始、提交或异常结束的声明
而是由EJB容器来为您作这些事情。
   让我们继续以银行出纳员为例，并假设客户程序调用了出纳员Bean，将实现银行帐号的转帐过程。按照声明型
事务，EJB容器会截取该请求并代替您的Bean组件来触发一个事务，也就是说，是容器向底层事务系统发布了事务
开始的声明，并触发事务。然后，容器就执行事务范围内的操作来处理您的EJB组件的调用。您的Bean组件可以作
任何想做的事情，例如，执行逻辑操作，写数据库。发送异步消息。调用其他企业级组件等。如果发生了问题，Bean
组件会通知容器：事务必须异常结束。当Bean组件完成操作后，会








当您在一个事务中调用实体Bean时，首先发生的动作是实体Bean需要通过ejbLoad()方法导入数据库数据，这个方
法需要在数据库上锁，并且保证实体Bean缓冲区是完整的，然后商务方法被调用。当事务被提交后，实体Bean的
ejbStore()方法被调用，这个方法将更新写入到数据库，并且执行解锁。这样，一个事务应该包括ejbLoad()、商
务方法以及ejbStore()，所以其中的任何一个操作失败，它们将全部失败。
如果我们使用Bean管理的事务，我们应该在Bean中编写代码执行begin()和commit()方法(可能在JDBC代码附近)
我们应该在ejbLoad()方法中开始一个事务，并且在ejbStore()方法中提交一个事务。但是，问题在于您并不调用
您的ejbCreate()方法和ejbStore()方法，而是由容器来调用。Bean不能保证这些方法以这个顺序执行，所以，
如果您一个ejbLoad()开始一个事务，那么有可能这个事务永远一个不会结束。
正因为如此，Bean管理的事务对于实体Bean是不合适的。实体Bean必须使用声明方式的事务。因为一个会话Bean
可以导入数据库数据，并且对这些数据进行操作，然后将这些数据存储，这些全部都发生在一个方法调用中，这样
就可以对事务进行直接控制，所以会话Bean和消息驱动Bean可以使用Bean管理的事务。
我们把这个讨论再延伸一步，即实体Bean并不是针对每一个方法调用都采取导入和存储操作。相反，它们针对每一
个事务来导入和存储数据。如果您的实体Bean不能很好地运行，那么可能就是因为再每一个get/set方法中都会有
数据库读写操作。解决方法是保证事务按顺序开始和结束，这其中可能包括很多实体Bean方法调用。通过使用事务
的属性来适当地控制事务的生命周期，您可以控制实体Bean的数据库读写时机。
编程方式控制的事务好处在于Bean可以完全控制事务边界。例如，您可以在一个Bean方法中使用编程方式控制的
事务来运行一系列的小型事务。相比之下，如果以声明方式或是客户端初始化方式控制事务的话，您的Bean只能
要么运行在一个事务中，要么不运行在一个事务中。
声明方式控制的事务好处在于他们比较简单，您不必在Bean中编写事务控制逻辑，这样可以节省编码时间，而且
不必改动源码就可以对事务进行优化。由于事务是自动地开始和结束的，这样也可以防止客户端程序误用Bean。
如果您是一个Bean提供商，这将完全小区大量的令人头疼的问题。