Correction on my previous remark: The re-read is on the version field. not entire row (i.e. SELECT t0.version...).
Catalina On Fri, May 30, 2008 at 10:42 AM, catalina wei <[EMAIL PROTECTED]> wrote: > Hi, > 1.Set openjpa.ConnectionRetainMode to "transaction" helped eliminating > connection close after SQL statement. > this property alone has no impact on user transaction commit request. > The commit is optimized away if there is no updates to any transactional > objects because the openjpa.Optimistic default is "true". > > 2. set openjpa.Optimistic to "false": > this property setting not only retains the connection, but also honors > user transaction commit request; > connection is only closed after transaction commits. > But there is performance penalty -- all transaction objects in the context > will be re-read from the datastore, even if there is no updates. > > Questions: > 1. what is the right set of the properties that users should use for > applications that run with default JDBC transaction isolatioin level = 8 > (TRANSACTION_SERIALIZABLE) and RESOURCE_LOCAL environment ? > > 2. Should OpenJPA detect that the default setting (Optimistic = true) > conflicting with JDBC's default and do something about it? > > Catalina > > > On Thu, May 29, 2008 at 2:30 PM, Patrick Linskey <[EMAIL PROTECTED]> > wrote: > >> Hi, >> >> It's my belief that if OpenJPA is configured to use a datastore >> transaction, then a commit will occur in this situation, but if using >> optimistic transactions, the commit will not occur unless OpenJPA believes >> that something noteworthy has happened during the transaction. >> >> Additionally, in default configurations in a RESOURCE_LOCAL environment, >> ConnectionRetainMode is set to on-demand, so OpenJPA might well use multiple >> different connections over the course of a given JPA transaction. >> >> -Patrick >> >> >> On May 30, 2008, at 3:14 AM, David Wisneski wrote: >> >> 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. >>> >> >> -- >> Patrick Linskey >> 202 669 5907 >> >> >
