The EntityTransaction interface is designed to imitate the UserTransaction interface
defined by the Java Transaction API, and the two behave very similarly. The main difference is
that EntityTransaction operations are implemented in terms of the transaction methods on
the JDBC Connection interface.

One example use of resource-local transactions in the Java EE environment
might be for logging. If your application requires an audit log stored in the database
that must be written regardless of the outcome of any JTA transactions, then a resource-local
entity manager may be used to persist data outside of the current transaction.

If that transaction rolls back, two things happen. The first is that the database transaction
will be rolled back. The next thing that happens is that the persistence context is cleared, detaching
all of our managed entity instances. If the persistence context was transaction-scoped, then it
is removed.

If there is a new entity that uses automatic primary key generation, there may be a
primary key value assigned to the detached entity. If this primary key was generated
from a database sequence or table, the operation to generate the number may have been
rolled back with the transaction. This means that the same sequence number could be
given out again to a different object. Clear the primary key before attempting to persist
the entity again, and do not rely on the primary key value in the detached entity.

If your entity uses a version field for locking purposes that is automatically maintained
by the persistence provider, it may be set to an incorrect value. The value in the entity
will not match the correct value stored in the database.

行， 我支持你哦

QUOTE:

---

原帖由 justforregister 于 2008-7-5 19:28 发表
行， 我支持你哦

---

去去去，学你的SAP去，这和SAP没有关系！

When persist() is invoked outside of a transaction, the behavior depends on the type of entity
manager. A transaction-scoped entity manager will throw a TransactionRequiredException as
there is no persistence context available in which to make the entity managed. Applicationmanaged
and extended entity managers will accept the persist request, causing the entity to
become managed, but no immediate action will be taken until a new transaction begins and
the persistence context becomes synchronized with the transaction.

The find() operation returns a managed entity instance in all cases except when invoked
outside of a transaction on a transaction-scoped entity manager. In this case, the entity instance is
returned in a detached state. It is not associated with any persistence context.

The getReference() call is effectively a performance optimization that removes the need to
retrieve the target entity instance.