openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wisneski" <wisnes...@gmail.com>
Subject Re: commit
Date Thu, 29 May 2008 20:09:20 GMT
When JPA does a close, because of connection pooling,  this does not
necessarily result in a close to the databsae.   JPA is issueing a
close (without a commit or rollback) and connection pooling is just
returning the connection to the free pool (without a commit or
rollback).  So a connection holding read locks is now is the free
pool.    So there might be too problems here -- 1.  JPA is not doing a
commit.  2  pooling is putting connections with active transactions
holding locks into the free pool.


On 5/29/08, Kevin Sutter <kwsutter@gmail.com> wrote:
> Okay, I just got confirmation from a reliable source :-) that close() does
> not require an implicit commit or rollback action.  It's provider specific.
> Most implementations will do either a commit or rollback of any outstanding
> transactions, but it is not a requirement.  In this particular case, it
> looks like Informix is one of those implementations that does nothing to
> outstanding transactions at close.
>
> So, I think we're back to removing the commit optimization that we have in
> OpenJPA.  If commit (or rollback) is invoked on the EntityTransaction
> interface, then we should pass that onto to the jdbc driver to let it do
> it's thing.
>
> Kevin
>
> On Thu, May 29, 2008 at 2:29 PM, Kevin Sutter <kwsutter@gmail.com> wrote:
>
> > Dave,
> > Another thought...  You say that OpenJPA is performing the close() on the
> > connection.  Doesn't the close() either commit or rollback any pending
> > transactions?  I know this can differ from provider to provider, but what is
> > happening in your scenario?  It would seem that if the close() is happening,
> > the jdbc provider should be cleaning up the connection (along with any
> > locks) before releasing it to the pool.
> >
> > Kevin
> >
> >
> > On Thu, May 29, 2008 at 2:10 PM, Kevin Sutter <kwsutter@gmail.com> wrote:
> >
> >> 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
View raw message