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?
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!
