Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of plinskey@gmail.com designates
 209.85.162.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SmaIaLZDC0yPzDWtBXkwRv9sSAW/OrgoZaDMKrHtfHhz9yIU7/2kd77udDdjqovpargiQAWfGImtZZuDsIJMVjWmclHkZlOhzQbnP5SojSWuIqQVcoR4ZHsCEa9RA837SJeBW8HciHQBR0cau3Z2G2DfytZNlSEGegBDEZmhqRk=
Message-ID: <7262f25e0802041514p7b289a6dg256db200f9032f2a@mail.gmail.com>
Date: Mon, 4 Feb 2008 15:14:18 -0800
From: "Patrick Linskey" <plinskey@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: optimistic locking bug?
In-Reply-To: <B638F0A9-1551-4DA7-80C2-BE53BC30BA51@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <75A0D7B9-86EA-44B9-AB9C-1491102D219D@joost.com>
	 <7262f25e0802041143y2540fd4dpffdbb55cb41f99a9@mail.gmail.com>
	 <B638F0A9-1551-4DA7-80C2-BE53BC30BA51@pobox.com>

> So, as a "best practice" for dealing with joined inheritance, have no
> cacading deletes for FKs in the db schema?

Does your metadata (annotations and XML) identify that you've got a
cascading constraint on that table? I would expect that if such
metadata exists, or if you tell OpenJPA to ask the DB for such
metadata (and it reports it properly), then your current code would be
fine.

-Patrick

On Feb 4, 2008 2:31 PM, Geir Magnusson Jr. <geir@pobox.com> wrote:
> That was my conclusion too, but I thought that when I was looking at
> the SQL logging, that wasn't the case.
>
> So, as a "best practice" for dealing with joined inheritance, have no
> cacading deletes for FKs in the db schema?
>
> geir
>
>
>
> On Feb 4, 2008, at 2:43 PM, Patrick Linskey wrote:
>
> > It sounds like OpenJPA is issuing delete statements for both tables,
> > but the cascade constraint from the first delete is causing the second
> > row to be deleted before the second delete statement is evaluated. So,
> > when the dependent row to be deleted is not found, OpenJPA assumes
> > that this is because a different transaction deleted the record.
> >
> > -Patrick
> >
> > On Feb 3, 2008 3:02 PM, Geir Magnusson Jr. <geir@joost.com> wrote:
> >> Single threaded code, 1 tx, my machine, no else one around...
> >>
> >> Code :
> >>
> >>
> >>         /*
> >>          * first _delete_ the ones we have
> >>          */
> >>         for (ShowInsertionPoint ip : list) {
> >>             OMUtil.getEntityManager().remove(ip);
> >>         }
> >>
> >>         OMUtil.getEntityManager().flush();
> >>
> >>
> >> Exception in thread "main" <openjpa-1.0.1-r420667:592145 fatal store
> >> error> org.apache.openjpa.persistence.OptimisticLockException:
> >> Optimistic locking errors were detected when flushing to the data
> >> store.  The following objects may have been concurrently modified in
> >> another transaction: [com.joost.model.ShowInsertionPoint-4590,
> >> com.joost.model.ShowInsertionPoint-4593]
> >>
> >> at
> >> org
> >> .apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:
> >> 2104)
> >>        at
> >> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954)
> >>        at
> >> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852)
> >>        at
> >> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1623)
> >>        at
> >> org
> >> .apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:
> >> 973)
> >>        at
> >> org
> >> .apache
> >> .openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:
> >> 488)
> >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>        at
> >> sun
> >> .reflect
> >> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> >> 39)
> >>        at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl
> >> .invoke(DelegatingMethodAccessorImpl.java:
> >> 25)
> >>        at java.lang.reflect.Method.invoke(Method.java:585)
> >>        at org.springframework.orm.jpa.SharedEntityManagerCreator
> >> $
> >> SharedEntityManagerInvocationHandler
> >> .invoke(SharedEntityManagerCreator.java:180)
> >>        at $Proxy8.flush(Unknown Source)
> >>        at
> >> com
> >> .joost
> >> .md
> >> .tools
> >> .importexport
> >> .fields
> >> .show
> >> .ShowInsertionPointsField
> >> .internalModify(ShowInsertionPointsField.java:
> >> 209)
> >>
> >> Note, that I'm not explicitly using optimistic locking.
> >>
> >> A ShowInsertionPoint is a sub of InsertionPoint, using joined
> >> inheritance.
> >>
> >> The tables :
> >>
> >> CREATE TABLE InsertionPoint (
> >>   id int(11) unsigned NOT NULL auto_increment,
> >>   itemType varchar(64) collate ascii_bin NOT NULL COMMENT 'The name
> >> of the table that defines any subclass information.',
> >>   insertionTime int(8) unsigned NOT NULL COMMENT 'in milliseconds',
> >>   sourceCode int(4) unsigned NOT NULL default '1',
> >>   quality float unsigned default NULL COMMENT 'Percentage (from 0.0
> >> to 100.0) giving a (human) estimate of how well this insertion point
> >> is placed wrt the content.',
> >>   PRIMARY KEY  (id),
> >>   KEY InsertionPoint_sourceCodeIndex (sourceCode),
> >>   CONSTRAINT InsertionPoint_sourceCodeFK FOREIGN KEY (sourceCode)
> >> REFERENCES InsertionPointSourceCode (`code`)
> >> ) ENGINE=InnoDB AUTO_INCREMENT=35960 DEFAULT CHARSET=ascii
> >> COLLATE=ascii_bin;
> >>
> >>
> >> CREATE TABLE ShowInsertionPoint (
> >>   id int(11) unsigned NOT NULL,
> >>   showId int(11) unsigned NOT NULL,
> >>   PRIMARY KEY  (id),
> >>   KEY ShowInsertionPoint_showIdIndex (showId),
> >>   CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
> >> InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
> >>   CONSTRAINT ShowInsertionPoint_showIdFK FOREIGN KEY (showId)
> >> REFERENCES VideoShow (id) ON DELETE CASCADE ON UPDATE CASCADE
> >> ) ENGINE=InnoDB DEFAULT CHARSET=ascii COLLATE=ascii_bin;
> >>
> >> The whole problem went away when I removed the constraint :
> >>
> >>   CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
> >> InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
> >>
> >> from ShowInsertionPoint.
> >>
> >> Am I doing something wrong?  Or is there a bug in OpenJPA?
> >>
> >> tia
> >>
> >> geir
> >>
> >>
> >>
> >
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>


-- 
Patrick Linskey
202 669 5907