[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3105: ------------------------------------ Hmm, sounds like a bug in [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...] and [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...] {quote} By default, a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED. Such a persistence context is automatically joined to the current JTA transaction, and updates made to the persistence context are propagated to the underlying resource manager. A container-managed persistence context may be specified to be of type SynchronizationType.UNSYNCHRONIZED. A persistence context of type SynchronizationType.UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the application. A persistence context of type SynchronizationType.UNSYNCHRONIZED is enlisted in a JTA transaction and registered for subsequent transaction notifications against that transaction by the invocation of the EntityManager joinTransaction method. The persistence context remains joined to the transaction until the transaction commits or rolls back. After the transaction commits or rolls back, the persistence context will not be joined to any subsequent transaction unless the joinTransaction method is invoked in the scope of that subsequent transaction. A persistence context of type SynchronizationType.UNSYNCHRONIZED must not be flushed to the database unless it is joined to a transaction. The application's use of queries with pessimistic locks, bulk update or delete queries, etc. result in the provider throwing the TransactionRequiredException. After the persistence context has been joined to the JTA transaction, these operations are again allowed. The application is permitted to invoke the persist, merge, remove, and refresh entity lifecycle operations on an entity manager of type SynchronizationType.UNSYNCHRONIZED independent of whether the persistence context is joined to the current transaction. After the persistence context has been joined to a transaction, changes in a persistence context can be flushed to the database either explicitly by the application or by the provider. If the flush method is not explicitly invoked, the persistence provider may defer flushing until commit time depending on the operations invoked and the flush mode setting in effect. If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back. If a persistence context of type SynchronizationType.UNSYNCHRONIZED has been joined to the JTA transaction, transaction rollback will cause the persistence context to be cleared and all pre-existing managed and removed instances to become detached. (See section 3.3.3.) When a JTA transaction exists, a persistence context of type SynchronizationType.UNSYNCHRONIZED is propagated with that transaction according to the rules in section 7.6.4.1 regardless of whether the persistence context has been joined to that transaction. {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira