Hi, BAD NEWS. Unfortuately, the approach of adding a TransactionListener did NOT work out:
2007-03-30 18:58:15,102 : ConnectionManager.freeConnections : WARNING:
Connection not closed by caller
2007-03-30 18:58:15,107 : JFactory.postInvoke : Could not commit
transaction:<4|false|0.9.7-incubating-SNAPSHOT>
org.apache.openjpa.util.CallbackException: The context has been closed.
The stack trace at which the context was closed is available if
Runtime=TRACE logging is enabled.
seems that the transactional context was closed before OpenJPA's TX
listener is invoked - can anybody explain that?
Hans
Am Donnerstag, den 29.03.2007, 10:09 -0700 schrieb Patrick Linskey:
> > to come from OpenJPA as it occurs since we've integrated OpenJPA.
> > So you think that this message comes from somewhere else? Interesting.
>
> Yes, I expect it's coming from your transaction manager.
>
> I suspect that the issue might have to do with the fact that you're not
> calling close() on your EMs. Sadly, the JPA spec requires that we must
> not allow operations to succeed after close() has been invoked.
>
> So I think that the goal here is to have OpenJPA automatically close the
> EntityManager upon completion of the transaction. This essentially
> emulates the container-managed transactional persistence context
> behavior of JPA in a normal Java EE 5 JTA environment, except that this
> EM will no longer be usable, whereas in a Java EE 5 environment,
> subsequent uses of the EM would bring to life a new persistence context.
> I think that you can do this by registering an
> org.apache.openjpa.event.EndTransactionListener. You can do so by adding
> this to your broker creation steps:
>
> broker.addTransactionListener(new AbstractTransactionListener() {
> public void afterCommitComplete(TransactionEvent te) {
> ((Broker) te.getSource()).close();
> }
>
> public void afterRollbackComplete(TransactionEvent te) {
> ((Broker) te.getSource()).close();
> }
> }
>
> Note that you could be slighly more efficient by implementing
> EndTransactionListener instead of extending AbstractTransactionListener,
> since OpenJPA would not need to invoke the no-op implementations of the
> other parts of the TransactionListener lifecycle. This should not be a
> significant performance hit, though.
>
> If somehow you're holding onto a reference to the EM across multiple
> transactions, or the pool is somehow doling out duplicates or something,
> you should now see exceptions thrown indicating that the EM is closed.
> Alternately, if the EM was holding onto resources that the appserver
> thinks should have been re-pooled, that should now go away.
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> > -----Original Message-----
> > From: Hans Prueller [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 29, 2007 3:44 AM
> > To: open-jpa-dev@incubator.apache.org;
> > open-jpa-dev@incubator.apache.org
> > Subject: Re: RE: WARNING: Connection not closed by caller -
> > messages produced byOpenJPA?
> >
> > Thank you for your ideas.
> >
> > I expected the message
> >
> > "WARNING: Connection not closed by caller"
> >
> > to come from OpenJPA as it occurs since we've integrated OpenJPA.
> > So you think that this message comes from somewhere else? Interesting.
> >
> > What we are doing is that we have several EJB2.1 CMP Entity Beans that
> > are created/updated within SLSB's methods. One of those CMP
> > Entity Beans
> > is now "converted" to be an OpenJPA Pojo. So we are working
> > on CMP EBs AND
> > OpenJPA persistent pojos within the same SLSB method (and TX).
> >
> > The really strange thing is that this co-existence worked
> > fine as long as there was only 1 application client issuing
> > requests to our server. As soon as we tested with 2
> > concurrent clients and both of them issued requests
> > simultaneously, we got that "Conflict writing entity bean" error.
> >
> > "The connection not closed by caller message" occurs
> > permanently. Perhaps the container does not close the
> > connection as it "knows" that there are other than CMP EB
> > clients (ie the openJPA pojo) using the same connection. So
> > perhaps it would be required to call em.close(); at the end
> > of every transaction?
> >
> > Meanwhile I will try to find out where this
> > "WARNING: Connection not closed by caller" message is coming from..
> >
> > hans
> >
> > -------- Original-Nachricht --------
> > Datum: Thu, 29 Mar 2007 01:46:19 -0700
> > Von: "Patrick Linskey" <[EMAIL PROTECTED]>
> > An: open-jpa-dev@incubator.apache.org
> > Betreff: RE: WARNING: Connection not closed by caller -
> > messages produced byOpenJPA?
> >
> > > So my feeling is that we need to get to the bottom of the "WARNING:
> > > Connection not closed by caller" line. Do you have any idea
> > what part of
> > > your framework is issuing that statement, and under what
> > situations it
> > > can happen? Can you get a stack from when it is issued?
> > >
> > >
> > > > 2007-03-27 14:57:07,160 : SEVERE : Logger.log : system
> > > > exception in business method:javax.ejb.EJBException: Conflict
> > > > writing entity bean
> > >
> > > Similarly, do you know more details about where this is failing? The
> > > exception seems to be happening because of concurrent
> > access to entity
> > > beans (i.e., not JPA entities). Are you using BMP entity
> > beans backed by
> > > JPA entities or something like that? Is it possible to get
> > a stack from
> > > where this message is logged, or at least more details
> > about what the
> > > biz method in question is?
> > >
> > > (None of the messages you've posted look like anything that OpenJPA
> > > would ever generate.)
> > >
> > > -Patrick
> > >
> > > --
> > > Patrick Linskey
> > > BEA Systems, Inc.
> > >
> > >
> > ______________________________________________________________
> > _________
> > > Notice: This email message, together with any attachments,
> > may contain
> > > information of BEA Systems, Inc., its subsidiaries and
> > affiliated
> > > entities, that may be confidential, proprietary,
> > copyrighted and/or
> > > legally privileged, and is intended solely for the use of
> > the individual
> > > or entity named in this message. If you are not the
> > intended recipient,
> > > and have received this message in error, please immediately
> > return this
> > > by email and then delete it.
> > >
> > > > -----Original Message-----
> > > > From: Hans J. Prueller [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, March 28, 2007 11:48 AM
> > > > To: open-jpa-dev
> > > > Subject: WARNING: Connection not closed by caller - messages
> > > > produced byOpenJPA?
> > > >
> > > > Hi together,
> > > >
> > > > I succeeded in integrating OpenJPA into our J2EE1.4
> > > > container, running side-by-side within the same JTA
> > transactions as
> > > > container managed EJB2.1 CMP entity beans.
> > > >
> > > > The lookup/creation of the EntityManager instances is
> > > > synchronizing with the JTA TXs as you suggested some weeks ago
> > > > on this list.
> > > >
> > > > After having a test server up and running for some days, we
> > > > are encountering lots of those messages:
> > > >
> > > > WARNING: Connection not closed by caller
> > > >
> > > > Suddenly (some hours later), a transactions fails:
> > > >
> > > > 2007-03-27 14:57:07,097 : WARNING : Logger.log : Conflict
> > > > with bb14:38:0:01fb60a716b0bed67c...80c679:
> > > > 2007-03-27 14:57:07,113 : WARNING : Logger.log : Current
> > > > Tx is bb14:38:0:01fb60a716b0bed67c...32a266:
> > > > 2007-03-27 14:57:07,144 : WARNING : Logger.log : You
> > > > should not modify the bean without a transactional context
> > > >
> > > >
> > > > 2007-03-27 14:57:07,160 : SEVERE : Logger.log : system
> > > > exception in business method:javax.ejb.EJBException: Conflict
> > > > writing entity bean
> > > >
> > > > Somehow this HAS to be related to the OpenJPA integration,
> > > > but the server was up for at least a day and running fine
> > > > until above error
> > > > occured. Any idea how this bad conflict could be caused?
> > > >
> > > > regards,
> > > > Hans
> > > >
> > >
> > > Notice: This email message, together with any attachments,
> > may contain
> > > information of BEA Systems, Inc., its subsidiaries and
> > affiliated
> > > entities, that may be confidential, proprietary,
> > copyrighted and/or legally
> > > privileged, and is intended solely for the use of the
> > individual or entity
> > > named in this message. If you are not the intended
> > recipient, and have
> > > received this message in error, please immediately return
> > this by email and
> > > then delete it.
> >
> > --
> > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
> > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
> >
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and have
> received this message in error, please immediately return this by email and
> then delete it.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
