You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Beniamin Mazan <it...@mazan.pl> on 2008/07/02 13:43:34 UTC

Bug in OpenJPA with cascade delete

I got 2 entities like below

@Entity....
class Product {
...
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy =
"product")
private List<SubProduct> children = new ArrayList<SubProduct>();
}

@Entity
class SubProduct {
....

@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.EAGER)
@JoinColumn(name = "product_id", nullable = false)
private Product product;

}

2) Database uses constraint on this relation - FOREIGN KEY, ON DELETE
CASCADE ON UPDATE CASCADE

3) persistence.xml has following properties
openjpa.Sequence=>class-table(Table=_SEQ_GENERATOR, UseAliases=true)"
openjpa.jdbc.MappingDefaults=>"ForeignKeyDeleteAction=cascade,JoinForeignKeyDeleteAction=cascade"
openjpa.jdbc.SchemaFactory=>"native(ForeignKeys=true)"
openjpa.jdbc.SynchronizeMappings=>"buildSchema(SchemaAction=refresh)" 
openjpa.jdbc.DBDictionary=>"postgres"
openjpa.Multithreaded=>"true"
openjpa.TransactionMode=>"managed"
openjpa.AutoDetach=>"commit"
openjpa.RestoreState=>"all"
openjpa.Optimistic"=>"true"

And what is the issue?

CASE I
Thing that I do in _one_ transaction:
1) get entity using remote interfejs of Fasade and make it "detached"
2) modify entity
3) return entity using method on facade's remote interface, that:
	a) merges changes and makes entity "attached"
	b) deletes entity from em

Any SQL statements are executed on transaction commit. There's no UPDATEs,
but only DELETEs.
What does go wrong?
At first are executed statements for entity Product and then for Subproduct.
As a result I get OptimisticLockException for SubProduct - because (I
suspect) of database's execution delete for "FOREIGN KEY ON DELETE CASCADE".

When I remove FK constraints, all works fine.


CASE II
Thing that I do in _one_ transaction:
1) get entity using remote interfejs of Fasade and make it "detached"
2) return entity (unmodified) using method on facade's remote interface,
that:
	a) merges changes and makes entity "attached"
	b) deletes entity from em
Everyting goes OK, cause At first are executed statements for entity
SunProduct and then for Product. 

Is there any workaround or I have to wait for patch for this issue ?
-- 
View this message in context: http://n2.nabble.com/Bug-in-OpenJPA-with-cascade-delete-tp219611p219611.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Re: Bug in OpenJPA with cascade delete

Posted by Beniamin Mazan <it...@mazan.pl>.


Fay Wang wrote:
> 
> Hi,
>     My patch is for relationships annotated with foreign key on delete
> cascade. Can you provide a test case that fails for insert or update due
> to foreign key violation?
> 
> -fay 
> 
> 

Maybe it's cause of my problems. I don't use OpenJPA specific annotations
like ForeignKey. It's difficult to extract small part of source from our
application that could show this error. I'm affraid that I can't send as
much source as it could be neccessary.

-----
thanks, Beniamin 
My homesite -  http://www.mazan.pl http://www.mazan.pl 
-- 
View this message in context: http://n2.nabble.com/Bug-in-OpenJPA-with-cascade-delete-tp219611p293128.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Re: Bug in OpenJPA with cascade delete

Posted by Fay Wang <fy...@yahoo.com>.
Hi,
    My patch is for relationships annotated with foreign key on delete cascade. Can you provide a test case that fails for insert or update due to foreign key violation?

-fay 


--- On Fri, 7/4/08, Beniamin Mazan <it...@mazan.pl> wrote:

> From: Beniamin Mazan <it...@mazan.pl>
> Subject: Re: Bug in OpenJPA with cascade delete
> To: users@openjpa.apache.org
> Date: Friday, July 4, 2008, 3:04 AM
> Sebastian Gauder wrote:
> > 
> > Does this patch fix the whole SQL reordering problem,
> or does it just 
> > work for relationships annotated with Cascade?
> > I still have problems à la "insert or update on
> table "customer" 
> > violates foreign key constraint
> "fk_address"...
> > 
> > Roger Keays schrieb:
> >> Roger Keays wrote:
> >>>
> >>> Sounds like issue 235, which I'm also
> stuck on:
> >>>
> >>>
> https://issues.apache.org/jira/browse/OPENJPA-235
> >>
> >> Fay's patch posted to that issue fixed the
> problem for me. I've posted 
> >> a binary at
> >>
> >> http://www.sunburnt.com.au/tmp/openjpa-1.1.0.jar
> >>
> >> You could try that version.
> >>
> >>>
> >>>
> >>
> > 
> 
> I've just put 1.1.0 patch to my Geronimo 2.1 and it
> hasn't resolve my
> problem. The exception is still the same.
> 
> -----
> --
> thanks
> Beniamin
> -- 
> View this message in context:
> http://n2.nabble.com/Bug-in-OpenJPA-with-cascade-delete-tp219611p221034.html
> Sent from the OpenJPA Users mailing list archive at
> Nabble.com.


      

Re: Bug in OpenJPA with cascade delete

Posted by Beniamin Mazan <it...@mazan.pl>.


Sebastian Gauder wrote:
> 
> Does this patch fix the whole SQL reordering problem, or does it just 
> work for relationships annotated with Cascade?
> I still have problems à la "insert or update on table "customer" 
> violates foreign key constraint "fk_address"...
> 
> Roger Keays schrieb:
>> Roger Keays wrote:
>>>
>>> Sounds like issue 235, which I'm also stuck on:
>>>
>>> https://issues.apache.org/jira/browse/OPENJPA-235
>>
>> Fay's patch posted to that issue fixed the problem for me. I've posted 
>> a binary at
>>
>> http://www.sunburnt.com.au/tmp/openjpa-1.1.0.jar
>>
>> You could try that version.
>>
>>>
>>>
>>
> 

I've just put 1.1.0 patch to my Geronimo 2.1 and it hasn't resolve my
problem. The exception is still the same.

-----
--
thanks
Beniamin
-- 
View this message in context: http://n2.nabble.com/Bug-in-OpenJPA-with-cascade-delete-tp219611p221034.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Re: Bug in OpenJPA with cascade delete

Posted by Sebastian Gauder <se...@denkwerk.com>.
Does this patch fix the whole SQL reordering problem, or does it just 
work for relationships annotated with Cascade?
I still have problems à la "insert or update on table "customer" 
violates foreign key constraint "fk_address"...

Roger Keays schrieb:
> Roger Keays wrote:
>>
>> Sounds like issue 235, which I'm also stuck on:
>>
>> https://issues.apache.org/jira/browse/OPENJPA-235
>
> Fay's patch posted to that issue fixed the problem for me. I've posted 
> a binary at
>
> http://www.sunburnt.com.au/tmp/openjpa-1.1.0.jar
>
> You could try that version.
>
>>
>> Beniamin Mazan wrote:
>>> I got 2 entities like below
>>>
>>> @Entity....
>>> class Product {
>>> ...
>>> @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, 
>>> mappedBy =
>>> "product")
>>> private List<SubProduct> children = new ArrayList<SubProduct>();
>>> }
>>>
>>> @Entity
>>> class SubProduct {
>>> ....
>>>
>>> @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
>>> FetchType.EAGER)
>>> @JoinColumn(name = "product_id", nullable = false)
>>> private Product product;
>>>
>>> }
>>>
>>> 2) Database uses constraint on this relation - FOREIGN KEY, ON DELETE
>>> CASCADE ON UPDATE CASCADE
>>>
>>> 3) persistence.xml has following properties
>>> openjpa.Sequence=>class-table(Table=_SEQ_GENERATOR, UseAliases=true)"
>>> openjpa.jdbc.MappingDefaults=>"ForeignKeyDeleteAction=cascade,JoinForeignKeyDeleteAction=cascade" 
>>>
>>> openjpa.jdbc.SchemaFactory=>"native(ForeignKeys=true)"
>>> openjpa.jdbc.SynchronizeMappings=>"buildSchema(SchemaAction=refresh)" 
>>> openjpa.jdbc.DBDictionary=>"postgres"
>>> openjpa.Multithreaded=>"true"
>>> openjpa.TransactionMode=>"managed"
>>> openjpa.AutoDetach=>"commit"
>>> openjpa.RestoreState=>"all"
>>> openjpa.Optimistic"=>"true"
>>>
>>> And what is the issue?
>>>
>>> CASE I
>>> Thing that I do in _one_ transaction:
>>> 1) get entity using remote interfejs of Fasade and make it "detached"
>>> 2) modify entity
>>> 3) return entity using method on facade's remote interface, that:
>>>     a) merges changes and makes entity "attached"
>>>     b) deletes entity from em
>>>
>>> Any SQL statements are executed on transaction commit. There's no 
>>> UPDATEs,
>>> but only DELETEs.
>>> What does go wrong?
>>> At first are executed statements for entity Product and then for 
>>> Subproduct.
>>> As a result I get OptimisticLockException for SubProduct - because (I
>>> suspect) of database's execution delete for "FOREIGN KEY ON DELETE 
>>> CASCADE".
>>>
>>> When I remove FK constraints, all works fine.
>>>
>>>
>>> CASE II
>>> Thing that I do in _one_ transaction:
>>> 1) get entity using remote interfejs of Fasade and make it "detached"
>>> 2) return entity (unmodified) using method on facade's remote 
>>> interface,
>>> that:
>>>     a) merges changes and makes entity "attached"
>>>     b) deletes entity from em
>>> Everyting goes OK, cause At first are executed statements for entity
>>> SunProduct and then for Product.
>>> Is there any workaround or I have to wait for patch for this issue ?
>>
>>
>


Re: Bug in OpenJPA with cascade delete

Posted by Roger Keays <ro...@ninthavenue.com.au>.
Roger Keays wrote:
> 
> Sounds like issue 235, which I'm also stuck on:
> 
> https://issues.apache.org/jira/browse/OPENJPA-235

Fay's patch posted to that issue fixed the problem for me. I've posted a 
binary at

http://www.sunburnt.com.au/tmp/openjpa-1.1.0.jar

You could try that version.

> 
> Beniamin Mazan wrote:
>> I got 2 entities like below
>>
>> @Entity....
>> class Product {
>> ...
>> @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy =
>> "product")
>> private List<SubProduct> children = new ArrayList<SubProduct>();
>> }
>>
>> @Entity
>> class SubProduct {
>> ....
>>
>> @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
>> FetchType.EAGER)
>> @JoinColumn(name = "product_id", nullable = false)
>> private Product product;
>>
>> }
>>
>> 2) Database uses constraint on this relation - FOREIGN KEY, ON DELETE
>> CASCADE ON UPDATE CASCADE
>>
>> 3) persistence.xml has following properties
>> openjpa.Sequence=>class-table(Table=_SEQ_GENERATOR, UseAliases=true)"
>> openjpa.jdbc.MappingDefaults=>"ForeignKeyDeleteAction=cascade,JoinForeignKeyDeleteAction=cascade" 
>>
>> openjpa.jdbc.SchemaFactory=>"native(ForeignKeys=true)"
>> openjpa.jdbc.SynchronizeMappings=>"buildSchema(SchemaAction=refresh)" 
>> openjpa.jdbc.DBDictionary=>"postgres"
>> openjpa.Multithreaded=>"true"
>> openjpa.TransactionMode=>"managed"
>> openjpa.AutoDetach=>"commit"
>> openjpa.RestoreState=>"all"
>> openjpa.Optimistic"=>"true"
>>
>> And what is the issue?
>>
>> CASE I
>> Thing that I do in _one_ transaction:
>> 1) get entity using remote interfejs of Fasade and make it "detached"
>> 2) modify entity
>> 3) return entity using method on facade's remote interface, that:
>>     a) merges changes and makes entity "attached"
>>     b) deletes entity from em
>>
>> Any SQL statements are executed on transaction commit. There's no 
>> UPDATEs,
>> but only DELETEs.
>> What does go wrong?
>> At first are executed statements for entity Product and then for 
>> Subproduct.
>> As a result I get OptimisticLockException for SubProduct - because (I
>> suspect) of database's execution delete for "FOREIGN KEY ON DELETE 
>> CASCADE".
>>
>> When I remove FK constraints, all works fine.
>>
>>
>> CASE II
>> Thing that I do in _one_ transaction:
>> 1) get entity using remote interfejs of Fasade and make it "detached"
>> 2) return entity (unmodified) using method on facade's remote interface,
>> that:
>>     a) merges changes and makes entity "attached"
>>     b) deletes entity from em
>> Everyting goes OK, cause At first are executed statements for entity
>> SunProduct and then for Product.
>> Is there any workaround or I have to wait for patch for this issue ?
> 
> 


Re: Bug in OpenJPA with cascade delete

Posted by Roger Keays <ro...@ninthavenue.com.au>.
Sounds like issue 235, which I'm also stuck on:

https://issues.apache.org/jira/browse/OPENJPA-235

Beniamin Mazan wrote:
> I got 2 entities like below
> 
> @Entity....
> class Product {
> ...
> @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy =
> "product")
> private List<SubProduct> children = new ArrayList<SubProduct>();
> }
> 
> @Entity
> class SubProduct {
> ....
> 
> @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
> FetchType.EAGER)
> @JoinColumn(name = "product_id", nullable = false)
> private Product product;
> 
> }
> 
> 2) Database uses constraint on this relation - FOREIGN KEY, ON DELETE
> CASCADE ON UPDATE CASCADE
> 
> 3) persistence.xml has following properties
> openjpa.Sequence=>class-table(Table=_SEQ_GENERATOR, UseAliases=true)"
> openjpa.jdbc.MappingDefaults=>"ForeignKeyDeleteAction=cascade,JoinForeignKeyDeleteAction=cascade"
> openjpa.jdbc.SchemaFactory=>"native(ForeignKeys=true)"
> openjpa.jdbc.SynchronizeMappings=>"buildSchema(SchemaAction=refresh)" 
> openjpa.jdbc.DBDictionary=>"postgres"
> openjpa.Multithreaded=>"true"
> openjpa.TransactionMode=>"managed"
> openjpa.AutoDetach=>"commit"
> openjpa.RestoreState=>"all"
> openjpa.Optimistic"=>"true"
> 
> And what is the issue?
> 
> CASE I
> Thing that I do in _one_ transaction:
> 1) get entity using remote interfejs of Fasade and make it "detached"
> 2) modify entity
> 3) return entity using method on facade's remote interface, that:
> 	a) merges changes and makes entity "attached"
> 	b) deletes entity from em
> 
> Any SQL statements are executed on transaction commit. There's no UPDATEs,
> but only DELETEs.
> What does go wrong?
> At first are executed statements for entity Product and then for Subproduct.
> As a result I get OptimisticLockException for SubProduct - because (I
> suspect) of database's execution delete for "FOREIGN KEY ON DELETE CASCADE".
> 
> When I remove FK constraints, all works fine.
> 
> 
> CASE II
> Thing that I do in _one_ transaction:
> 1) get entity using remote interfejs of Fasade and make it "detached"
> 2) return entity (unmodified) using method on facade's remote interface,
> that:
> 	a) merges changes and makes entity "attached"
> 	b) deletes entity from em
> Everyting goes OK, cause At first are executed statements for entity
> SunProduct and then for Product. 
> 
> Is there any workaround or I have to wait for patch for this issue ?