[
https://issues.apache.org/jira/browse/CAMEL-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733896#comment-13733896
]
Brett E. Meyer edited comment on CAMEL-5932 at 8/8/13 7:47 PM:
---------------------------------------------------------------
Hey [~davsclaus], apologies again. Life has gotten away from us lately...
I pushed the current state to https://github.com/brmeyer/camel/tree/CAMEL-5932.
There are a couple of test failures that I still need to work through. If
someone else has time to take a look, great. Otherwise, I'll see what I can do
(although freetime has been diminishing).
It replaces the use of Spring's JpaTemplate with direct usage of EntityManager
within a TransactionTemplate.
Admittedly, I'm not 100% on how Spring's JpaTemplate worked. However, based
off of some of the unit tests and the original architecture of the
consumer/producer, it appears that one EntityManager was opened and shared.
Typically, it's best to use one EM per unit of work, rather than per request or
global. However, in this context, the global context makes a bit of sense.
It's left open and closed only on the endpoint's #doStop. Anyone disagree with
that?
One failure is JpaUsePersistTest#produceExistingEntityShouldThowAnException().
Even though debugging showed that JpaUsePersistTest#entityManager and
JpaProducer#entityManager were the same instance (Spring's
LocalEntityManagerFactoryBean returns the same EM instance for
#createEntityManager() until the EM is explicitly closed, I believe), it's not
throwing an exception anymore if the same entity is persisted twice. I'm not
sure if that was something specific that the JpaTemplate was providing (and
OpenJPA doesn't natively do what we expect) or if there's something else stupid
that I'm missing.
JpaProducerConcurrentTest is failing also, but I haven't had a chance to really
dig into it.
was (Author: 3riverdev):
Hey [~davsclaus], apologies again. Life has gotten away from us lately...
I pushed the current state to https://github.com/brmeyer/camel/tree/CAMEL-5932.
There are a couple of test failures that I still need to work through. If
someone else has time to take a look, great. Otherwise, I'll see what I can do
(although freetime has been diminishing).
It replaces the use of Spring's JpaTemplate with direct usage of EntityManager
within a TransactionTemplate. My best guess about the test failures brings up
a discussion point:
Admittedly, I'm not 100% on how Spring's JpaTemplate worked. However, based
off of some of the unit tests and the original architecture of the
consumer/producer, it appears that one EntityManager was opened and shared.
Typically, it's best to use one EM per unit of work, rather than per request or
global. However, in this context, the global context makes a bit of sense.
It's left open and closed only on the endpoint's #doStop. Anyone disagree with
that?
One failure is JpaUsePersistTest#produceExistingEntityShouldThowAnException().
Even though debugging showed that JpaUsePersistTest#entityManager and
JpaProducer#entityManager were the same instance (Spring's
LocalEntityManagerFactoryBean returns the same EM instance for
#createEntityManager() until the EM is explicitly closed, I believe), it's not
throwing an exception anymore if the same entity is persisted twice. I'm not
sure if that was something specific that the JpaTemplate was providing (and
OpenJPA doesn't natively do what we expect) or if there's something else stupid
that I'm missing.
JpaProducerConcurrentTest is failing also, but I haven't had a chance to really
dig into it.
> Update camel-jpa for Spring 3.1
> -------------------------------
>
> Key: CAMEL-5932
> URL: https://issues.apache.org/jira/browse/CAMEL-5932
> Project: Camel
> Issue Type: Improvement
> Components: camel-jpa
> Reporter: Brett E. Meyer
> Fix For: 2.12.0
>
>
> Spring 3.1 deprecated JpaTemplate and JpaCallback in favor of directly acting
> upon JPA's EntityManager. Replace JpaTemplateTransactionStrategy and make
> other improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
