If the stateful session bean is largely self-contained, that is, it does not call other session
beans and does not need its persistence context propagated, then a default transaction attribute
type of NOT_SUPPORTED may be worth considering.

When a stateful session bean with an
extended persistence context creates another stateful session bean that also uses an extended
persistence context, the child will inherit the parent’s persistence context.

There is no limit to
the number of application-managed persistence contexts that may be synchronized with a
transaction, but only one container-managed persistence context will ever be associated. This
is one of the most important differences between application-managed and container-managed
entity managers.

An application-managed entity manager participates in a JTA transaction in one of two
ways. If the persistence context is created inside the transaction, then the persistence provider
will automatically synchronize the persistence context with the transaction. If the persistence
context was created earlier (outside of a transaction or in a transaction that has since ended),
the persistence context may be manually synchronized with the transaction by calling
joinTransaction() on the EntityManager interface. Once synchronized, the persistence context
will automatically be flushed when the transaction commits.

靠， 真能水

QUOTE:

---

原帖由 justforregister 于 2008-7-5 18:48 发表
靠， 真能水

---

最重要的概念！不懂这个JPA就等于没学！

NND，总比那些双手互搏的好吧？

不但双手互搏，还问一些垃圾问题，我靠！

While EntityManagerFactory
instances are thread-safe, EntityManager instances are not.

If the persistence context becomes synchronized
with a transaction, changes will still be written to the database when the transaction commits,
even if the entity manager is closed.