I appears that when running in a RESOURCE_LOCAL environment with a nonJTA datasource, in either J2EE or J2SE, when an application calls EntityManager.getEntityTransaction().commit() a sql commit may or may not actually occur. If there are no updated objects flushed to the database, then the commit is quietly ignored. However, the user may be holding read locks if the transactionIsolation was repeatable-read and these locks will not be released. The user may have done nativeSQL which may or may not have done updates or the user may have obtained the connection from the Broker and have done his or her own sql directly to the database.
OpenJPA is being too aggressive in its optimization of commits (and rollbacks) and this may need to be disabled or scaled back. We are seeing locking and deadlock problems where there should be none.
