You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Jason Hanna <ja...@gmail.com> on 2007/04/27 19:13:08 UTC
Merge Detached Entity Problem
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.
Re: Merge Detached Entity Problem
Posted by Jason Hanna <ja...@gmail.com>.
Hi Roger,
I don't know anything about your project or environment, but I've been
doing some testing with PostgreSQL today and I'm finding it seems to
work much better with OpenJPA than MySQL.
I've recently come out of the corporate world, and Oracle was our
"standard" database platform. I've just started working with open
source db platforms, and I'm finding MySQL has some limitations that
might prove problematic when using OpenJPA and programming robust
database-backed web applications. I know it's a supported platform,
but I'd be willing to bet there are a lot more caveats (and remaining
bugs) when using MySQL as opposed to Oracle or PostgreSQL.
I'm sure some of the experts on this list can speak to this point, but
MySQL apparently does not support deferred foreign key constraints.
In my particular use case, I was trying to merge a detached object
that contained a reference to another detached object. The cascade
update seemed to succeed only if both detached objects contained
changes.
Adding the @Version annotation and columns to my tables fixed the
problem, but then I ran into an intermittent 'Optimistic Lock'
exception when attempting to remove the same type of detached object.
It appeared to be a race condition, as sometimes the delete would
succeed, and other times it would fail. I'm speculating that this
occured because I had cascade delete enabled on my foreign key
constraint and CascadeType.ALL enabled for my referenced object.
Since I was using MySQL, the cascade delete on the foreign key
constraint couldn't be deferred until transaction commit. It would
sometimes execute prior to OpenJPA execution of the 2nd delete
statement. I believe that's where the (legitimate) intermittent
optimistic lock exception was coming from for this removal use case.
I've just finished setting up my database, schema, and tables on
PostgreSQL 8.2.4. I'm finding that with deferred foreign key
constraints enabled, my cascading issues seem to have disappeared. As
an added bonus I was able to revert to the initial code I created for
my DAOs because JPA was working without any additional (and seemingly
unnecessary) manipulation of my referenced objects.
If alternate database platforms are an option, I'd recommend looking
at PostgreSQL. Support for deferred constraints, plus better handling
of BLOBs and full support for multi-version concurrency control
(MVCC).
Cheers,
-jmh
On 4/29/07, roger.keays <ro...@ninthavenue.com.au> wrote:
>
>
> Jason Hanna wrote:
> >
> > 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 just fixed a similar issue in my app [1]. Maybe it is the same problem
> with foreign key constraints [2]
>
> [1] http://www.nabble.com/forum/ViewPost.jtp?post=10247539&framed=y
> [2] http://www.nabble.com/forum/ViewPost.jtp?post=7395124&framed=y
> --
> View this message in context: http://www.nabble.com/Merge-Detached-Entity-Problem-tf3658825.html#a10247785
> Sent from the open-jpa-dev mailing list archive at Nabble.com.
>
>
Re: Merge Detached Entity Problem
Posted by "roger.keays" <ro...@ninthavenue.com.au>.
Jason Hanna wrote:
>
> 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 just fixed a similar issue in my app [1]. Maybe it is the same problem
with foreign key constraints [2]
[1] http://www.nabble.com/forum/ViewPost.jtp?post=10247539&framed=y
[2] http://www.nabble.com/forum/ViewPost.jtp?post=7395124&framed=y
--
View this message in context: http://www.nabble.com/Merge-Detached-Entity-Problem-tf3658825.html#a10247785
Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: IRC
Posted by Patrick Linskey <pl...@bea.com>.
Hi,
I am on the channel from time to time, but not regularly.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -----Original Message-----
> From: Phill Moran [mailto:pjmoran@rogers.com]
> Sent: Monday, April 30, 2007 7:04 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: IRC
>
> Does anyone actually monitor the IRC chat? I have logged on
> the last few business days and received no responses. Should
> I stick to emails as the preferred communications method?
>
> Phill
>
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
IRC
Posted by Phill Moran <pj...@rogers.com>.
Does anyone actually monitor the IRC chat? I have logged on the last few
business days and received no responses. Should I stick to emails as the
preferred communications method?
Phill
RE: Merge Detached Entity Problem
Posted by Patrick Linskey <pl...@bea.com>.
That is an odd manifestation of the problem. Definitely worth
investigation.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -----Original Message-----
> From: Jason Hanna [mailto:jason.m.hanna.at.coincident@gmail.com]
> Sent: Friday, April 27, 2007 11:55 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Merge Detached Entity Problem
>
> 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 <ja...@gmail.com> 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.
> >
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Merge Detached Entity Problem
Posted by Jason Hanna <ja...@gmail.com>.
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 <ja...@gmail.com> 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.
>