openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: optimistic locking bug?
Date Tue, 05 Feb 2008 16:29:44 GMT

On Feb 4, 2008, at 6:14 PM, Patrick Linskey wrote:

>> 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 looked through the spec, and couldn't find a way to do that - I know  
how to define cascade in terms of entities, but this isn't that.

> 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.

Yeah, I thought I was asking OpenJPA to read the schema :

     <bean id="emf"  
class 
="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
         <property name="dataSource" ref="dataSource" />
         <property name="jpaVendorAdapter" ref="jpaVendor" />
         <property name="persistenceUnitName" value="pu" />
         <property name="persistenceXmlLocation"  
value="classpath:persistence.xml"/>
         <property name="jpaPropertyMap">
             <map>
                 <entry key="openjpa.jdbc.SchemaFactory"  
value="native(ForeignKeys=true)"/>
             </map>
         </property>
      </bean>
>
>
> -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


Mime
View raw message