[
https://issues.apache.org/jira/browse/OPENJPA-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133222#comment-18133222
]
ASF subversion and git services commented on OPENJPA-3045:
----------------------------------------------------------
Commit af470bc2b4f411c790ec4a6f3993377df94e78d9 in openjpa's branch
refs/heads/OPENJPA-3045 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=af470bc2b ]
[OPENJPA-3045] Order the locked query in TestPessimisticLocks so the skipped
row is fixed
> 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
>
> {{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)
