openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
Subject RE: commit
Date Mon, 09 Jun 2008 04:09:37 GMT
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
View raw message