This happens most times if you have Cascade.PERSIST enabled. This makes your 1:n list a 'part' of your 'main entity'. The idea is that once you change a part of your logical area you need to prevent concurring changes on the whole area. Otherwise consistency cannot get guaranteed. Thus a touch on the 'main entity' gets performed to ensure an OptimisticLockingException in case someone else tries to change the 'logic area' at the same time.
Think about a Customer with 1:n Address entries. Imagine what would happen if 2 independent users would add the same address? This would not result in a db constraint error but still the logical consistency of the Customer entry would be broken! By touching the parent entity this can be detected and would lead to optimistic locking. LieGrue, strub ----- Original Message ----- > From: mwalter <marc.wal...@sbb.ch> > To: users@openjpa.apache.org > Cc: > Sent: Monday, December 10, 2012 4:40 PM > Subject: Why is parent version incremented on update of child entity? > > I found out that on update of a child entity the parent version field is > incremented as well. Is this default behaviour? Is it possible to change the > increment strategy somehow so that the parent version does not change? > > I'm using OpenJPA 1.2.3 (WebSphere V7), LockManager is set to > "version". > > Thanks for any help and/or explanation! > > > > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/Why-is-parent-version-incremented-on-update-of-child-entity-tp7582115.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
