An update - I was not using the @Version annotation in my item
definition. After updating my class with the annotation and adding
additional database column, my original reported problem disappears.
My first read of the documentation led me to believe the @Version
annotation was a best practice, but not necessary.
From the OpenJPA User's Guide, Section 1.4:
---start
Note
OpenJPA fully supports version fields, but does not require them for
concurrency detection. OpenJPA can maintain surrogate version values
or use state comparisons to detect concurrent modifications. See
Section 7, Additional JPA Mappings in the Reference Guide.
---end
I seem to have resolved my immediate issue, but perhaps someone can
set me straight on the expected behavior when the @Version annotation
is not present.
Thanks,
-jmh
On 4/27/07, Jason Hanna [EMAIL PROTECTED] wrote:
Hi All,
I'm running into a problem developing a web application that utilizes
JSF and JPA. Not sure if my problem is related to an OpenJPA bug, or a
flaw in my approach. I'm hoping you can help.
In my web application, a user selects an item to edit from a table
of all available items. They are then directed to a page containing a
form which allows them to modify the details of the item they selected
(pretty standard web app stuff).
Upon submission, the backing bean connected to this form invokes the
update method of the item's data access object. The DAO in turn
creates and EntityManager from the EntityManagerFactory, starts a
transaction, merges the detached object, and commits the transaction.
If any value is modified on the item edit form, the detached object is
merged and successfully committed. That's good. Now for the problem:
If the detached object is NOT modifed (edit form submitted w/o any
changes) the merge will fail on the EntityManager transaction commit
with the following error:
2|true|0.9.5-incubating
org.apache.openjpa.persistence.RollbackException: Optimistic locking
errors were detected when flushing to the data store. The following
objects may have been concurrently modified in another transaction:
[com.coincident.green.beans.User-com.coincident.green.beans.User-1]
I've read through the lifecycle management documentation and don't see
why attempting to merge an unchanged detached entity would result in
an exception.
I could probably detect that no updates were made at my JSF managed
bean and avoid the merge operation altogether, but what happens when
my item references other managed entities and I want to utilize
cascade merge?
Hoping you all might have some thoughts. Here are a few details about
my environment:
Sun JDK 1.5.0_06
Apache Tomcat 5.5.20
MyFaces 1.1.3
OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo)
MySQL 5.0.27 (Community)
Thanks! Please let me know if you require any more information.
Regards,
-jmh
Jason M. Hanna
President/Founder
Coincident, Inc.
