@Claus,
That's for sure may be not correct, but it's how I see it:
To my understanding in the sense of the CRUD operation one can C, U or D an
entity through the JpaProducer, however
only R through a JpaConsumer, so don't get the point why JpaConsumer should
do entityManager.flush() at all, for
example while polling! Other than that I don't think that calling
entityManager.flush() could help in any way in
the case the JPA-Provider throws PersistenceException in JpaConsumer.poll()
and that gets just swallowed & flush()
gets called afterwards. To me that PersistenceException would mean that some
serious problems on the DB occured while
reading through a JPA or Native Query on the JpaConsumer from which we could
ever/never recover ourself:
PersistenceException cause = null;
int messagePolled = 0;
try {
messagePolled = processBatch(CastUtils.cast(answer));
} catch (Exception e) {
if (e instanceof PersistenceException) {
cause = (PersistenceException) e;
} else {
cause = new PersistenceException(e);
}
}
if (cause != null) {
if (!isTransacted()) {
LOG.warn("Error processing last message due: {}.
Will commit all previous successful processed message, and ignore this last
failure.", cause.getMessage(), cause);
entityManager.flush();
} else {
// rollback all by throwning exception
throw cause;
}
}
In the sense of the expected ACID properties I think having that
consumer.transacted default to false would violate the A (all or nothing).
Maybe true would be better. Again that's just my 2 cents which may be not
correct at all.
Thanks, Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Misleading-jmx-statistics-on-jpa-component-tp4960503p4994753.html
Sent from the Camel - Users mailing list archive at Nabble.com.
