You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Daryl Stultz <da...@6degrees.com> on 2009/06/08 21:33:22 UTC
openjpa.LockManager
Hi all,
I'm adding OpenJPA to a large application. I'm getting "Optimistic locking
errors". I have no @Version members and I am fine with a "he who commits
last wins" approach. So I set
<property name="openjpa.LockManager" value="none" />
in persistence.xml but it still occurs.
I hope there's a simple explanation, but here's more information:
I have an entity with a collection member (CascadeType.ALL) and
em.remove(em.merge(entity)) is failing on a child of the collection. I
happen to be instantiating the entity (and children) by traversing a
java.sql.ResultSet (because I've failed thus far to convert the SQL to
JPQL), then cloning it before deleting it.
Any idea what could cause the error when locking is disabled?
Thanks.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: openjpa.LockManager
Posted by Daryl Stultz <da...@6degrees.com>.
2009/6/10 Daryl Stultz <da...@6degrees.com>
>
>
> Yup, I forgot the @ForeignKey annotation. I have added it and reverted to
> my cascade/not deferrable setting and it seems to be working. Thanks!
>
>
Well, the @ForeignKey did take care of the ordering of the SQL, but I
deployed it to a test server and it failed the original way. I said above
that I reverted to cascade/not deferrable, I did but on the wrong database
instance. So I ultimately had to define the foreign key in the DB as
"cascade no action deferrable initialy deferred" (PostgreSQL) to get it to
work.
I have to say it's rather confusing to have an optimistic locking error
thrown when the lock manager is set to none. Not sure if there is some other
feedback that can be given in a case like this.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: openjpa.LockManager
Posted by Daryl Stultz <da...@6degrees.com>.
On Wed, Jun 10, 2009 at 3:44 AM, Miłosz Tylenda <mt...@o2.pl> wrote:
> Daryl,
>
> I suppose you need to tell OpenJPA to take foreign keys into account. See
> this topic:
>
Yup, I forgot the @ForeignKey annotation. I have added it and reverted to my
cascade/not deferrable setting and it seems to be working. Thanks!
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: openjpa.LockManager
Posted by Miłosz Tylenda <mt...@o2.pl>.
Daryl,
I suppose you need to tell OpenJPA to take foreign keys into account. See this topic:
http://n2.nabble.com/Inconsistent-behaviour-with-Bi-directional-One-to-Many-Mapping.-tp2570464p2570464.html
Regards,
Milosz
> On Tue, Jun 9, 2009 at 8:32 AM, Daryl Stultz wrote:
>
> >
> >
> > The foreign key from B to A is set to cascade delete and is not deferred.
> > Do I need to change either of these?
> >
> > It seems to be that the foreign key must not cascade and must be deferable.
> It is working now.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: openjpa.LockManager
Posted by Daryl Stultz <da...@6degrees.com>.
On Tue, Jun 9, 2009 at 8:32 AM, Daryl Stultz <da...@6degrees.com> wrote:
>
>
> The foreign key from B to A is set to cascade delete and is not deferred.
> Do I need to change either of these?
>
> It seems to be that the foreign key must not cascade and must be deferable.
It is working now.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: openjpa.LockManager
Posted by Daryl Stultz <da...@6degrees.com>.
On Mon, Jun 8, 2009 at 3:33 PM, Daryl Stultz <da...@6degrees.com> wrote:
> Hi all,
>
> I'm adding OpenJPA to a large application. I'm getting "Optimistic locking
> errors". I have no @Version members and I am fine with a "he who commits
> last wins" approach. So I set
>
> <property name="openjpa.LockManager" value="none" />
>
> in persistence.xml but it still occurs.
>
I've got a unit test recreating the problem. I create A with one child B and
persist. I load A and delete it (remove). About half the time it is
successful. I find that sometimes the delete query for A is issued before
the delete for B. And sometimes the reverse. When B is deleted before A, no
problem. When A is deleted before B it fails.
The foreign key from B to A is set to cascade delete and is not deferred. Do
I need to change either of these?
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com