[
https://issues.apache.org/jira/browse/CAMEL-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-7053:
--------------------------------
Description:
The current implementation of the JPA endpoint is created more for using it as
a queue for one JVM.
This change performs the lock with timeout=0, causing a NOWAIT to be used where
implementations support it.
Ideally the lock should be performed using refresh() instead of lock() to
prevent dirty read exceptions but Hibernate's implementation throws the wrong
exception.
https://hibernate.atlassian.net/browse/HHH-8786
Currently OpenJPA throws the wrong exception for both lock and refresh so the
test uses hibernate. See this jira:
https://issues.apache.org/jira/browse/OPENJPA-2461
The default lock of WRITE=OPTIMISTIC_FORCE_INCREMENT performs the lock too late
and their are various jpa implementation problems (OpenJPA doesn't lock it in
memory, hibernate performs the delete before the increment). In nearly every
use case PESSIMISTIC_WRITE is more correct.
was:
The current implementation of the JPA endpoint is catered more for using it as
a queue for one JVM.
This change performs the lock with timeout=0, causing a NOWAIT to be used where
implementations support it.
Ideally the lock should be performed using refresh() instead of lock() to
prevent dirty read exceptions but Hibernate's implementation throws the wrong
exception.
https://hibernate.atlassian.net/browse/HHH-8786
Currently OpenJPA throws the wrong exception for both lock and refresh so the
test uses hibernate. See this jira:
https://issues.apache.org/jira/browse/OPENJPA-2461
The default lock of WRITE=OPTIMISTIC_FORCE_INCREMENT performs the lock too late
and their are various jpa implementation problems (OpenJPA doesn't lock it in
memory, hibernate performs the delete before the increment). In nearly every
use case PESSIMISTIC_WRITE is more correct.
> JPA Skip locked entities
> ------------------------
>
> Key: CAMEL-7053
> URL: https://issues.apache.org/jira/browse/CAMEL-7053
> Project: Camel
> Issue Type: New Feature
> Components: camel-jpa
> Affects Versions: 2.12.1
> Reporter: Chris Watts
> Attachments: skipLockedJpa.patch
>
>
> The current implementation of the JPA endpoint is created more for using it
> as a queue for one JVM.
> This change performs the lock with timeout=0, causing a NOWAIT to be used
> where implementations support it.
> Ideally the lock should be performed using refresh() instead of lock() to
> prevent dirty read exceptions but Hibernate's implementation throws the wrong
> exception.
> https://hibernate.atlassian.net/browse/HHH-8786
> Currently OpenJPA throws the wrong exception for both lock and refresh so the
> test uses hibernate. See this jira:
> https://issues.apache.org/jira/browse/OPENJPA-2461
> The default lock of WRITE=OPTIMISTIC_FORCE_INCREMENT performs the lock too
> late and their are various jpa implementation problems (OpenJPA doesn't lock
> it in memory, hibernate performs the delete before the increment). In nearly
> every use case PESSIMISTIC_WRITE is more correct.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
