Community
Participate
Working Groups
Build Identifier: the app is following： === Query query = em.createQuery("select i from RowLockEntity i where i.id=:id"); query.setParameter("id", id); query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType); entity = (RowLockPesEntity)query.getSingleResult(); === The generated SQL of above app by eclipselink-2.2.0.v20110202-r8913 as following. === SELECT ID,ENT_TYPE, NAME, OPT_LOCK_VER FROM ROWLOCKENTITY WHERE (ID = ?)") === The generated SQL does not contain pessimistic lock. This problem occurred not only in SQL Server 2008, but also in Oracle, Derby and so on. Reproducible: Always
What is the value of lockType in your code below?
Originally reported as http://java.net/jira/browse/GLASSFISH-16746 Tom, Following code snippet reproduces the issue. em.getTransaction().begin(); Query query = em.createQuery("select e from Employee e where e.id=:id"); query.setParameter("id", 1); query.setHint(org.eclipse.persistence.config.QueryHints.PESSIMISTIC_LOCK,org.eclipse.persistence.config.PessimisticLock.Lock); query.getSingleResult();
Created attachment 197057 [details] fix the problem of QueryHints.PESSIMISTIC_LOCK I think this patch fixes the issue. Could you please confirm it.
Looking at patch
Is this problem recreatable outside of GlassFish? I am running a similar query and can see the FOR UPDATE string on both Oracle and MySql. @NamedQuery( name="findAllEmployeesByFirstName", query="SELECT OBJECT(employee) FROM Employee employee WHERE employee.firstName = :firstname" ) Query query = em.createNamedQuery("findAllEmployeesByFirstName"); query.setHint("eclipselink.pessimistic-lock", PessimisticLock.Lock); query.setParameter("firstname", "Sarah"); List results = query.getResultList(); Note: Our DerbyPlatform has limited support for "FOR UPDATE" It is possible that if we are not detecting the database platform properly we would not issue the FOR UPDATE. Try explicitly specifying your database platform with the eclipselink.target-database persistence unit property.
This is repdroducible outside GlassFish. Here is code snippet that reproduces it running against Derby public static void main(String[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("em"); EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); javax.persistence.Query query = em.createQuery("select e from Employee e where e.id=:id"); query.setParameter("id", 1); query.setHint(org.eclipse.persistence.config.QueryHints.PESSIMISTIC_LOCK,org.eclipse.persistence.config.PessimisticLock.Lock); //--Comment setHint above and uncomment following line to see FOR UPDATE being generated //query.setLockMode(javax.persistence.LockModeType.PESSIMISTIC_READ); query.getSingleResult(); em.getTransaction().commit(); }
This is repdroducible either inside GlassFish or outside Glassfish if meets the conditions as folowing. 1) use the QueryHints.PESSIMISTIC_LOCK === query.setHint(QueryHints.PESSIMISTIC_LOCK,lockType); === 2) Query with primary key === SELECT ID,ENT_TYPE, NAME, OPT_LOCK_VER FROM ROWLOCKENTITY WHERE (ID = ?)") // Here ID is the primary key ===
Thanks. I can now reproduce.
Addition: In EclipseLink, when query by primary key use the ReadObjectQuery. when query no by primary key use the ReportQuery. In the other hand, Toplink always use the ReportQuery no matter whether query by primary key or not. the logic of ReadObjectQuery.checkForCustomQuery() is different from the logic of ReportQuery.checkForCustomQuery(). so cannot reproduce in toplink.
Checked changes into 2.3 Reviewed - user submitted fix reviewed by Tom Ware Testing: Added Test to JUnitJPQLComplexTestSuite Tested with JPA and Core LRG 2.3.1 check in to come when stream opens
correction: Checked changes into Trunk
Checked into 2.3.1
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
