openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <mik...@apache.org>
Subject Re: commit
Date Mon, 09 Jun 2008 14:53:44 GMT
Well, in JSE there might not be a connection pool per se. The connection
would be closed and it's locks would be dropped when its GC'ed.

I believe there is an issue in the JEE environment though. Here's what I've
found.

I've seen a case where we obtain a connection. Use it (just a query) then
close it without calling commit or rollback. OpenJPA assumes that the
connection has not started a transaction (in OpenJPA terms we haven't
started a STORE_TRANSACTION).

A testcase to do this is straightforward (from memory) :
em.getTransaction().begin();

List<Owner> owners = em.createQuery("Select o from Owner
o").getResultList();

em.getTransaction().commit(); // or rollback IIRC

You won't see db locks unless the isolation level is RR or higher, but I
believe this is a valid problem.

Some of this is from memory - I took a look at the problem last week but got
wrapped up in maven issues and haven't had a chance to look again. I'll take
another look this afternoon.

-Mike



On Sun, Jun 8, 2008 at 11:09 PM, Evan Ireland <eireland@sybase.com> wrote:

> Is this for the Java SE case, or the container-managed case?
>
> > -----Original Message-----
> > From: Patrick Linskey [mailto:plinskey@gmail.com]
> > Sent: Monday, 9 June 2008 3:11 p.m.
> > To: dev@openjpa.apache.org
> > Subject: Re: commit
> >
> > Hi,
> >
> > > Putting connections with active transactions into a free pool is an
> > > error,
> > > regardless of whether the active transactions hold locks or not.
> >
> > My understanding is that the issue at hand is around the behavior of
> > connection retention within a given transaction, not the validity of
> > the connection pool.
> >
> > I definitely agree that the connection pool should never have
> > connections associated with active transactions in them.
> >
> > -Patrick
> >
> > On Jun 9, 2008, at 12:23 PM, Evan Ireland wrote:
> >
> > > Putting connections with active transactions into a free pool is an
> > > error,
> > > regardless of whether the active transactions hold locks or not.
> > >
> > > Perhaps the underlying issue here has nothing to do with locks per
> > > se, but
> > > just connection/pool management.
> > >
> > >> -----Original Message-----
> > >> From: Patrick Linskey [mailto:plinskey@gmail.com]
> > >> Sent: Monday, 9 June 2008 11:37 a.m.
> > >> To: dev@openjpa.apache.org
> > >> Subject: Re: commit
> > >>
> > >> Hi,
> > >>
> > >> The JPA 1.0 spec only defines em.lock() in terms of optimistic
> > >> locking, so the behavior wrt. connections is undefined (I contend
> > >> that
> > >> optimistic locking can be implemented per the spec with no connection
> > >> affinity until the very end of the transaction).
> > >>
> > >> Under the new JPA 2.0 datastore locking semantics, the connection
> > >> used
> > >> to obtain the lock will need to be retained for the duration of the
> > >> transaction.
> > >>
> > >> When configured to do datastore locking, current versions of OpenJPA
> > >> should be retaining the connection after an appropriate lock() call.
> > >>
> > >> -Patrick
> > >>
> > >> On May 30, 2008, at 7:18 AM, Craig L Russell wrote:
> > >>
> > >>> Hi David,
> > >>>
> > >>> You bring up a good point, that in JPA the assumption is that until
> > >>> commit, the provider can get a pooled connection and then return it
> > >>> to the pool after it does whatever it likes.
> > >>>
> > >>> Except after a lock is acquired explicitly via the em.lock method,
> > >>> which implies (to me) that the user wants to hold locks until the
> > >>> transaction is over. And the connection used to acquire the lock is
> > >>> no longer eligible to be put back into the pool.
> > >>>
> > >>> Is this your understanding?
> > >>>
> > >>> Craig
> > >>>
> > >>> On May 29, 2008, at 1:09 PM, David Wisneski wrote:
> > >>>
> > >>>> 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!
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>> 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!
> > >>>
> > >>
> > >> --
> > >> Patrick Linskey
> > >> 202 669 5907
> > >
> > >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>
>

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