Hi,
Besides UPGRADE_SKIPLOCKED, we also have the option of passing the
SKIP_LOCKED timeout to other LockModes, like PESSIMISTIC_READ:
Query query = session.createQuery(
"select j from BatchJob j", BatchJob.class )
.setMaxResults( maxResult )
.unwrap( Query.class )
.setLock
Part of the problem here is that the actual effects of these lock-modes
really depend (in part) on the transaction-isolation-level configured for
the Connection Hibernate uses, but unfortunately we do not necessarily know
the isolation level - we do have a setting for letting the user configure
an
Per our discussion on HipChat, +1.
On 03/23/2017 06:53 AM, Vlad Mihalcea wrote:
> --works
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)
>
> --fails
> select TOP(?) abstractsk0_.id as id1_0_, abstract
I'm not using SQL Server myself but this sounds reasonable.
Mit freundlichen Grüßen,
*Christian Beikov*
Am 23.03.2017 um 11:53 schrieb Vlad Mihalcea:
> --works
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processe
