Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Have JPA PessimisticLockScope.EXTENDED propagate the same LockModeType

Description

According to JPA specification, when using PessimisticLockScope.EXTENDED:

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.

So if I define the following Parent/Child associations:

Because a Post has a collection of Comment components, an EXTENDED lock request should lock the joined table rows as well, without locking the actual Comment row-level locks:

But the output SQL looks like this:

So, only the root Entity was locked, when we should have locked the post_comments associated rows as well.

Attachments

2

Activity

Show:

Vlad Mihalcea January 21, 2016 at 9:10 AM

I added another zip with a test for reattachment too:

which generates this query:

So, the lock scope is never extended to the joined table.
I think this could be a very handy feature and it's important to have it since it's demanded by the JPA specs.

Steve Ebersole January 20, 2016 at 3:25 PM

I am curious what happens if you attempt the extended locking if the Post is not yet associated with the PC. Does it work then? You'd have to use a query with that hint.

As far as locking an entity already associated with PC, the point where this "breaks down" is org.hibernate.event.internal.DefaultLockEventListener#onLock. At the moment we only do the cascade if the incoming entity is being reassociated. However, this is a Hibernate-specific feature (true reattachment); in the JPA case the entity has to already be in the PC by contract. In that condition the cascading it skipped.

Vlad Mihalcea June 10, 2015 at 3:05 PM

Point taken. You are right, I tried to understand what the specs say, but you clearly know it better than me. It's a feature request then. Thanks for the clarifications.

Steve Ebersole June 10, 2015 at 2:50 PM

Also, we need to see votes as to whether this is actually an improvement. It is not necessarily.

Steve Ebersole June 10, 2015 at 2:49 PM

I think you are reading into what the spec says, rather than the spec specifically saying that. Yes it says phantoms will "still be possible", but phantoms will "still be possible" is read locks are acquired.

Also keep in mind that the Hibernate team has 2 members on the JPA EG. So we have a pretty good idea of what the "authors had in mind" because what makes it into the spec is supposed to be discussed amongst the EG members. And the exact type of lock to propagate was not discussed.

Anyway, if that passage is the basis of classifying this report as a bug I believe this actually needs to be a feature request instead. I am not against it, but its just a lower priority.

Details

Assignee

Reporter

Priority

Created February 27, 2015 at 7:47 AM
Updated January 21, 2016 at 9:10 AM