> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, December 17, 2009 12:38 PM
> To: [email protected]
> Subject: Re: Get "You cannot access the EntityTransaction when using
> managed transactions." when I implement @Transactional methods with
> OpenJPA
> 
> Hi,
> 
> I'm happy to hear of your success.
> 
> If you would like to help future generations of OpenJPA developers
> avoid what you had to experience, would you consider opening a JIRA to
> suggest where the documentation could be improved?

I'm willing, but I don't know yet that I understand the details of what
I did wrong or right, so I'm not sure what additional statements could
be made.  The point about the mismatch between the transaction-type and
the "data-source" settings is a good candidate.  I guess I can at least
make that statement.

> 
> Thanks,
> 
> Craig
> 
> On Dec 17, 2009, at 8:21 AM, KARR, DAVID (ATTCINW) wrote:
> 
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]]
> >> Sent: Wednesday, December 16, 2009 1:07 PM
> >> To: [email protected]
> >> Subject: Re: Get "You cannot access the EntityTransaction when
using
> >> managed transactions." when I implement @Transactional methods with
> >> OpenJPA
> >>
> >> Hi,
> >>
> >> There are two transaction models you can use in a Java EE
container.
> >> If you use the JTA datasource, you need to use the Java EE
> >> transaction
> >> manager. If you use only a non-JTA datasource, you can manage the
> >> transactions using EntityTransaction.
> >>
> >> I don't know the details with regard to integrating with Spring,
but
> >> you might be ok with just using the non-JTA datasource in your
> >> environment. If you use the JTA datasource, you need to use the
> >> managed transaction interface (I recall you can look this up as a
> >> JNDI
> >> resource).
> >
> > A bunch of things just "came together" at the end of the day
> > yesterday.
> > I'm glad it's working, but I think I need to understand better why
> > it's
> > now working.  I'd appreciate any ideas about this.
> >
> > It looks like the last problem I had is that I was setting
> > "non-jta-data-source", and not "jta-data-source", but my
> > "transaction-type" was "JTA".  I changed that to "RESOURCE_LOCAL"
> > and my
> > last error went away.  In addition, the other problem I had had,
> where
> > the test case with "categories with child categories" would throw an
> > NPE
> > in "pcReplaceField()", also went away.
> >
> > Throughout all of this, I'm using a DataSource defined in WebLogic,
> > so I
> > can get connection pooling (as opposed to just doing a direct
> > connection).
> >
> > I started out with my Controller layer directly calling my DAO
layer,
> > which referenced the EntityManager.  That's when I noticed the NPE
in
> > "pcReplaceField()" for one of my two existing test cases.  At that
> > point
> > I thought perhaps it might be a good idea to implement a
> transactional
> > layer between the Controller and DAO, even if it was only read-
> > only.  I
> > put the "@Transactional" annotation on that service layer method,
and
> > that produced the InvalidStateException.  After that, I ended up
> > changing "jta-data-source" to "non-jta-data-source" and the
> > "transaction-type" to "RESOURCE_LOCAL".  That fixed both problems.
> >
> > Although the OpenJPA doc, JPA spec, and Spring doc mentions
> > "transaction-type", "JTA", and "RESOURCE_LOCAL", neither of them
> > really
> > explain the choices and the real implications and consequences of
> > those
> > choices.
> >
> > On a related topic, if a persistence.xml has "transaction-type" set
> to
> > "JTA" with no "jta-data-source" setting, is it reasonable to say
that
> > there's no way that could work?  If so, wouldn't this be a
reasonable
> > thing for the framework to validate and present a message in that
> > case?
> >
> >> On Dec 16, 2009, at 8:45 AM, KARR, DAVID (ATTCINW) wrote:
> >>
> >>> I have an app using Spring 2.5.6, OpenJPA 1.2.1, and WebLogic
> >>> 10.3.2.  I
> >>> specified a JTA datasource in the persistence.xml.  I have a
Spring
> >>> controller that calls my DAO class which uses the EntityManager.
> >> This
> >>> is working ok with respect to transactions.  As my app is only
> going
> >>> to
> >>> be reading the database, I would think I wouldn't need
> transactions.
> >>> However, because of one problem I'm having with traversing an
> >>> association path, I thought I would try to implement a
> transactional
> >>> service layer, and do the association walking within that layer.
> >>>
> >>> So, I added a class with a "@Transactional" method and put that in
> >>> between the Controller and the DAO.  Now, I'm seeing the following
> >>> exception stack trace:
> >>>
> >>> --------------------
> >>> Caused by:
> >>> org.springframework.transaction.CannotCreateTransactionException:
> >>> Could
> >>> not open JPA EntityManager for transaction; nested exception is
> >>> <openjpa-1.2.1-r752877:753278 nonfatal user error>
> >>> org.apache.openjpa.persistence.InvalidStateException: You cannot
> >>> access
> >>> the EntityTransaction when using managed transactions.
> >>>   at
> >>> org
> >>>
> >
.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransaction
> >>> Manager.java:375)
> >>>   at
> >>> org
> >>>
> >
.springframework.transaction.support.AbstractPlatformTransactionManag
> >>> er.getTransaction(AbstractPlatformTransactionManager.java:374)
> >>>   at
> >>> org
> >>>
> >
.springframework.transaction.interceptor.TransactionAspectSupport.cre
> >>> ateTransactionIfNecessary(TransactionAspectSupport.java:263)
> >>>   at
> >>> org
> >>>
> >
.springframework.transaction.interceptor.TransactionInterceptor.invok
> >>> e(TransactionInterceptor.java:101)
> >>>   at
> >>> org
> >>>
> >
.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
> >>> lectiveMethodInvocation.java:171)
> >>>   at
> >>> org.springframework.aop.framework.Cglib2AopProxy
> >>> $DynamicAdvisedIntercept
> >>> or.intercept(Cglib2AopProxy.java:635)
> >>>   at
> >>>
> com.att.ecom.dynamiccontent.service.CatalogService$$EnhancerByCGLIB$
> >>> $5a7
> >>> c3444.retrieveCatalogTree(<generated>)
> >>>   at
> >>>
> com.att.ecom.dynamiccontent.content.Content.getCatalog(Content.java:
> >>> 35)
> >>> --------------------
> >>
> >> Craig L Russell
> >> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> >> 408 276-5638 mailto:[email protected]
> >> P.S. A good JDO? O, Gasp!
> >
> 
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:[email protected]
> P.S. A good JDO? O, Gasp!

Reply via email to