Delete OptimisticLock exception, when entity appears 2x in cascade graph

[areider <op...@reider.net>]

I'm using 1.2.3_Snapshot (that comes with IBM RAD 7.5). 

I'm having an issue with remove operation receiving an Optimistic Lock
exception.

My domain includes a structure which would be similar to a Department and
Employees. Thus:
All employees own a relationship to a Department
Employees optionally own a relationship to another Employee in the same
department.

class Department {
@OneToMany(mappedBy="department", cascade=CascadeType.ALL)
List<Employee> employees;
}

class Employee {

@ManyToOne
Department department;

@ManyToOne
Employee manager;

@OneToMany(mappedBy="manager",cascade=CascadeType.ALL)
List<Employee> employees;

public boolean equals(){
// entities are equal if their primary keys are equal
}
public hashCode(){
// entities with same primary key have the same hashCode
}

So an Employee has a foreign key (FK) to a Department as well as
(optionally) another Employee.

The FK to department has referential integrity (RI) and is not nullable. 
The FK to another Employee has RI, and is not nullable.
I'm not at liberty to change this structure or the RI.

Consider the following instance of a department

Dept
	JoesBoss
		Joe
	Joe
	
So we have an entity structure where an entity may appear more than once in
the graph of objects reachable by a cascaded delete. Is this supported?
	
When I try to removing Dept, I get an OptimisticLock exception that Joe is
currently being modified in another transaction. Apparently it tries to
remove Joe twice (at least I see that @PreRemove and @PostRemove are each
entered for Joe twice). 

Shouldn't it be avoiding the 2nd remove of Joe since it is equal() to the
1st instance found?

(At some point, possibly before implementing equals()/hashcode, i was
getting an error from DB2 indicating an RI was violated trying to delete
JoesBoss before Joe (since JoesBoss happens to be before Joe in the
department list), so perhaps the RI (delete sequence) issue is orthogonal to
the lock issue).

Is this a known problem and/or has it been fixed in a later release?

--
View this message in context: http://openjpa.208410.n2.nabble.com/Delete-OptimisticLock-exception-when-entity-appears-2x-in-cascade-graph-tp6882907p6882907.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Delete OptimisticLock exception, when entity appears 2x in cascade graph

[areider <op...@reider.net>]

I made some changes to tell OpenJPA to observe foreign key constraints. I
didn't do it with SynchronizeMappings because it is not crystal clear to me
exactly under what circumstances the MappingTool might ever make attempt to
make changes to the database. (I am in a strictly 'bottom-up' environment).

Instead, I added 
			<property name="openjpa.jdbc.MappingDefaults" 
		
value="jpa(ForeignKeyDeleteAction=restrict,JoinForeignKeyDeleteAction=restrict)"/>

to persistence.xml which I believe tells OpenJPA to treat all relationships
as if they are based on foreign keys. Is this equivalent?

I got the same error as before. In the (very voluminous) OpenJPA walkback
(too many printStackTrace()s?) I actually see 2 different errors, an RI
error, and the optimistic lock error. I'm not sure which one is the root
error.

But judging by the @preremove and @postremove calls ahead of the error (if
in fact the order of those callbacks reflects the batch order), it does
appear that the deletes are in fact being done in an order that is
respecting the constraints, but some entities appear to be getting deleted
more than once. 

In the actual object graph, some Employees have more than one instance, eg
the Joe employee under the department as well as under the JoesBoss
employee. 

So could this be a problem that is specific to having entities with multiple
foreign keys pointing to other entities within the in the same graph that is
being deleted and thus occuring more than once in the graph, rather than a
problem with the sort?

I have other serious issues with this model, because in reality, the entity
i'm calling an Employee itself has a very large subgraph under it, and it is
obviously inefficient for it to be repeated in the object graph as equal
(but not identical)  objects. So at best, this structure is not very nicely
mapped to objects at all. Nevertheless, our data modelers insist this is a
very common and frequent pattern, and must be supported as is by the ORM.


--
View this message in context: http://openjpa.208410.n2.nabble.com/Delete-OptimisticLock-exception-when-entity-appears-2x-in-cascade-graph-tp6882907p6891334.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Delete OptimisticLock exception, when entity appears 2x in cascade graph

[areider <op...@reider.net>]

Thanks for the reply. i just saw it after my following reply to Pinaki. I do
in fact have 			<property name="openjpa.jdbc.SchemaFactory"
value="native(ForeignKeys=true)"/>

and i did add  <property name="openjpa.jdbc.UpdateManager"
value="batching-constraint"/> 

but it did not change the result. As I said in the other reply I'm
definitely seeing an ordering happening from the 'leafs' of the graph to the
'root', so it does look to me like a entity duplication issue as opposed to
an ordering issue.


--
View this message in context: http://openjpa.208410.n2.nabble.com/Delete-OptimisticLock-exception-when-entity-appears-2x-in-cascade-graph-tp6882907p6891354.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Delete OptimisticLock exception, when entity appears 2x in cascade graph

[Michael Dick <mi...@gmail.com>]

Just to add to Pinaki's reply.

OpenJPA can order the SQL updates appropriately, but only if the
openjpa.jdbc.UpdateManager is set to one of the constraint update managers
(constraint or batching-constraint). See this
section<http://openjpa.apache.org/builds/apache-openjpa-1.2.3-SNAPSHOT/docs/manual/manual.html#openjpa.jdbc.UpdateManager>of
the manual for a little more information.

Note that using OpenJPA in RAD may have a different default value of this
configuration option. It might be best to explicitly set it to constraint to
ensure you're getting the expected value.

If you're sure you're using the constraint update manager, then you can tell
OpenJPA to read the database schema with the openjpa.SchemaFactory property.
Set it to 'native' in your persistence.xml file like this :
<property name="openjpa.jdbc.SchemaFactory" value="native"/>.

The SchemaFactory property controls how OpenJPA reads schema information.
The SynchronizeMappings property from Pinaki's email tells OpenJPA to build
the database objects based on your entities. They're related, but slightly
different.

Hope this helps
-mike


On Thu, Oct 13, 2011 at 8:16 AM, Pinaki Poddar <pp...@apache.org> wrote:

> Hi,
> > I'm not at liberty to change this structure or the RI.
>   did you tell OpenJPA to read the database foreign key constraints?
> OpenJPA
> update can topologically sort a to-be-committed graph of objects to honor
> database constraints -- but the quality of sort depends on supplied
> information.
>  If you have not, please see openjpa.jdbc.SynchronizeMappings property.
>
> -----
> Pinaki Poddar
> Chair, Apache OpenJPA Project
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Delete-OptimisticLock-exception-when-entity-appears-2x-in-cascade-graph-tp6882907p6888860.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Delete OptimisticLock exception, when entity appears 2x in cascade graph

[Pinaki Poddar <pp...@apache.org>]

Hi,
> I'm not at liberty to change this structure or the RI. 
  did you tell OpenJPA to read the database foreign key constraints? OpenJPA
update can topologically sort a to-be-committed graph of objects to honor
database constraints -- but the quality of sort depends on supplied
information. 
  If you have not, please see openjpa.jdbc.SynchronizeMappings property.

-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/Delete-OptimisticLock-exception-when-entity-appears-2x-in-cascade-graph-tp6882907p6888860.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.