-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JPA find and locking a lazy referenced entity fails #39258
Comments
Also, I tried to reproduce this with just Hibernate alone, and it looks like the error does NOT occur there. So, I would assume that this really is a Quarkus bug this time around. My hibernate test case: package org.hibernate.orm.test.locking;
import jakarta.persistence.Entity;
import jakarta.persistence.FetchType;
import jakarta.persistence.Id;
import jakarta.persistence.JoinColumn;
import jakarta.persistence.LockModeType;
import jakarta.persistence.ManyToOne;
import jakarta.persistence.Version;
import org.hibernate.Hibernate;
import org.hibernate.testing.orm.junit.EntityManagerFactoryScope;
import org.hibernate.testing.orm.junit.JiraKey;
import org.hibernate.testing.orm.junit.Jpa;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import static org.junit.Assert.assertFalse;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
@JiraKey("HHH-?????")
@Jpa(
annotatedClasses = {
LockFindAndLockReferencedTest.MainEntity.class,
LockFindAndLockReferencedTest.ReferencedEntity.class
}
)
public class LockFindAndLockReferencedTest {
@BeforeAll
public void setUp(EntityManagerFactoryScope scope) {
scope.inTransaction(
entityManager -> {
final ReferencedEntity e1 = new ReferencedEntity( 0L );
entityManager.persist( e1 );
final MainEntity e3 = new MainEntity( 0L, e1 );
entityManager.persist( e3 );
}
);
}
@Test
public void testFindAndLockAfterLock(EntityManagerFactoryScope scope) {
scope.inTransaction(
entityManager -> {
// First find and lock the main entity
MainEntity m = entityManager.find( MainEntity.class, 0L, LockModeType.PESSIMISTIC_WRITE );
assertNotNull( m );
ReferencedEntity lazyReference = m.referencedLazy();
assertNotNull( lazyReference );
assertFalse( Hibernate.isInitialized( lazyReference ) );
// Then find and lock the referenced entity
ReferencedEntity lazyEntity = entityManager.find( ReferencedEntity.class, 0L, LockModeType.PESSIMISTIC_WRITE );
assertNotNull( lazyEntity );
assertEquals( LockModeType.PESSIMISTIC_WRITE, entityManager.getLockMode( lazyEntity ) );
} );
}
@Entity(name = "MainEntity2")
public static class MainEntity {
@Id
private long id;
@Version
private long tanum;
private String name;
@ManyToOne(targetEntity = ReferencedEntity.class, fetch = FetchType.LAZY)
@JoinColumn(name = "LAZY_COLUMN")
private ReferencedEntity referencedLazy;
protected MainEntity() {
}
public MainEntity(long id, ReferencedEntity lazy) {
this.id = id;
this.referencedLazy = lazy;
}
public ReferencedEntity referencedLazy() {
return referencedLazy;
}
}
@Entity(name = "ReferencedEntity2")
public static class ReferencedEntity {
@Id
private long id;
@Version
private long tanum;
protected ReferencedEntity() {
}
public ReferencedEntity(long id) {
this.id = id;
}
}
} |
Hey @mensinda thanks for reporting this issue. Quarkus applies a few settings that are different from the standalone Hibernate ORM configuration. Hence we've recently created this new test template to make it behave a bit closer to how Quarkus works: https://github.com/hibernate/hibernate-test-case-templates/blob/main/orm/hibernate-orm-6/src/test/java/org/hibernate/bugs/QuarkusLikeORMUnitTestCase.java I've tried your case using that template and the issue is reproducable within it. Could you please give it a try and report the bug to the ORM JIRA here https://hibernate.atlassian.net/browse/HHH ? Thanks! |
This test case demonstrates that currently find and locking an entity that is already lazly loaded (by an already locked referencing entity) fails. https://hibernate.atlassian.net/browse/HHH-17828 quarkusio/quarkus#39258
This test case demonstrates that currently find and locking an entity that is already lazly loaded (by an already locked referencing entity) fails. https://hibernate.atlassian.net/browse/HHH-17828 quarkusio/quarkus#39258
I have also managed to reproduce it with the
|
@marko-bekhta the existence of that specific template should probably be documented somewhere. If there is already documentation, I couldn't find any. |
Thanks for creating the ticket and reproducer upstream!
that's a good idea, I'm not sure where to add it though ... maybe @yrodiere would have a suggestion? |
For Quarkus, not really, since the point of this reproducer is that it's useful only when a bug isn't actually about Quarkus. For ORM, adding stuff to the various readmes in the test case templates repo would be enough as far as I'm concerned. |
The upstream issue has been resolved in Hibernate version 6.4.5, I believe this can be closed as well. |
Describe the bug
Trying to find and lock (via
EntityManager.find(*.class, ..., LockModeType.PESSIMISTIC_WRITE)
) of an Entity fails if that entity:@Version
attributefetch = FetchType.LAZY
Abbreviated example from https://github.com/mensinda/quarkus-stuff/tree/lockLazyLock to illustrate:
Expected behavior
No exceptions on the second
em.find(..., LockModeType.PESSIMISTIC_WRITE);
Actual behavior
How to Reproduce?
I have created a minimal test case for this issue: https://github.com/mensinda/quarkus-stuff/tree/lockLazyLock
Steps to reproduce:
lockLazyLock
branch of https://github.com/mensinda/quarkus-stuff/tree/lockLazyLockmvn clean verify
Output of
uname -a
orver
Linux XXXXXXX 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
openjdk version "17.0.10" 2024-01-16
Quarkus version or git rev
3.8.1
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
Additional information
No response
The text was updated successfully, but these errors were encountered: