About Question enthuware.oce-jpad.v6.2.373 :

Moderator: admin

Post Reply
__JJ__
Posts: 125
Joined: Thu Jul 05, 2018 6:44 pm
Contact:

About Question enthuware.oce-jpad.v6.2.373 :

Post by __JJ__ »

This is a little confusing, but does it all add up to this:

Under NORMAL scope, if a child is locked, the relationship to the parent is locked because the child owns the FK to the parent, and therefore the parent cannot be deleted (or have its PK changed, although of course that would not be good practice anyway). An example here would be locking Item, which has a reference to Seller; locking the child (Item) means the parent (Seller) cannot be deleted because there is an FK in Item that points to it.

Under EXTENDED scope, if Item is locked, then any children of Item (eg ItemDetail; in this case Item is the parent) are STILL not locked; but what IS locked are rows in a join table. I say this because the spec says:
In addition to the behavior for PessimisticLockScope.NORMAL, element collections and relationships owned by the entity that are contained in join tables will be locked if the javax.persistence.lock.scope property is specified with a value of PessimisticLockScope.EXTENDED. The state of entities referenced by such relationships will not be locked (unless those entities are explicitly locked). Locking such a relationship or element collection generally locks only the rows in the join table or collection table for that relationship or collection. This means that phantoms will be possible.
Qualifying that relationships that are contained in join tables means, in the (perhaps normal) case that ItemDetail has an FK to Item, without there being a join table in the middle, means that even under EXTENDED scope (IF there is no join table), ItemDetail children are not locked, so in such a case there is no change in behaviour between NORMAL and EXTENDED. Is that correct? If there IS a join table, the join table rows (just the rows) containing an FK back to Item (and indeed also back to ItemDetail) ARE locked, but again, not the ItemDetail rows themselves; they are locked only to the extent that there is an FK in the join table that points back to them.
Phantoms are possible in all cases because row locks are taken not table locks.

Is that all correct? Thanks very much in advance.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.373 :

Post by admin »

Qualifying that relationships that are contained in join tables means, in the (perhaps normal) case that ItemDetail has an FK to Item, without there being a join table in the middle, means that even under EXTENDED scope (IF there is no join table), ItemDetail children are not locked, so in such a case there is no change in behaviour between NORMAL and EXTENDED. Is that correct?
Correct. That would by my interpretation as well.
Paul.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 26 guests