openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: commit
Date Thu, 29 May 2008 19:10:42 GMT
Dave,
I agree that OpenJPA should not be optimizing out this commit call.  We
should fix that in the OpenJPA code.

OpenJPA does not pool connections.  In this particular scenario, the pooling
is performed by WebSphere.  So, the last part of your comment is related to
how the Connection Manager (for whatever app server environment) processes
the non-jta-data-sources.

Kevin

On Thu, May 29, 2008 at 1:32 PM, David Wisneski <wisneskid@gmail.com> wrote:

> If the user call EntityTransaction.commit(),  I think that OpenJPA
> should definitely issue a commit.   Another related problems, is that
> OpenJPA is closing the connection and putting it back into the free
> pool after every sql statement,  even if there are still read locks
> being held by the active transaction.    This would be OK if the user
> does a EntityManager operation outside a transaction scope,  but it
> should not be occurring when the user has explicitly done an
> EntityTransaction.begin().
>
>
> On 5/29/08, Craig L Russell <Craig.Russell@sun.com> wrote:
> > Good observation. Please file a JIRA and a test case.
> >
> > Seems like OpenJPA should keep track of whether a jdbc Connection was
> ever
> > acquired by the transaction. Not sure how to know whether read locks were
> > acquired...
> >
> > So are you suggesting that OpenJPA should *always* commit the
> transaction?
> >
> > Craig
> >
> >
> > On May 29, 2008, at 10: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.
> > >
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System
> > http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message