[
https://issues.apache.org/jira/browse/OPENJPA-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133923#comment-18133923
]
ASF subversion and git services commented on OPENJPA-3045:
----------------------------------------------------------
Commit 3f50f752544bdb1be0b3f8a4906e9a5ecd5f5ea8 in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=3f50f7525 ]
[OPENJPA-3045] Order the locked query in TestPessimisticLocks so the skipped
row is fixed (#243)
> TestPessimisticLocks fails on PostgreSQL because a query with OFFSET has no
> ORDER BY
> ------------------------------------------------------------------------------------
>
> Key: OPENJPA-3045
> URL: https://issues.apache.org/jira/browse/OPENJPA-3045
> Project: OpenJPA
> Issue Type: Test
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> {{TestPessimisticLocks.testQueryAfterFindWithPessimisticLocks}} fails in the
> scheduled Databases workflow on PostgreSQL (11, 15 and 18):
> {noformat}Unexpected find succeeded. Should throw a
> PessimisticLockException.{noformat}
> It is the only failure on PostgreSQL; {{openjpa-persistence-jdbc}} passes.
> The test locks Employee 2 in one EntityManager and expects this query in
> another to block:
> {code}
> select e from Employee e where e.id < 10 -- setFirstResult(1),
> PESSIMISTIC_READ
> {code}
> It assumes the OFFSET skips Employee 1, but there is no ORDER BY. PostgreSQL
> returns the rows in physical order, which can change between tests because
> each setUp deletes and inserts the rows again. When Employee 2 is skipped,
> nothing blocks. This is a test problem: the lock SQL is correct, and it
> passes locally.
> {{testFindAfterQueryWithPessimisticLocks}} was already changed for the same
> reason. Fix: add {{order by e.id}} to the query.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
