I do not have a strong opinion about it, but I'm leaning towards defining
this as an SPI
On 22 March 2017 at 18:15, Steve Ebersole wrote:
> Coming back to this to see if people see this as an API concern, of if we
> should define this as an SPI.
>
> One potential argument for making it an API is
--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_, abstractsk0_.processed as
processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock, readpast)
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
Having this as an SPI could be useful to Hibernate Search.
For example when we generate queries to efficiently scroll on large
batched of entities while fetching a selection of relations having
some more details on such relations could allow us to suggest better
fetch plans.
That said, I should p
I don't have a strong lean either way too.
Either way, this gives integrators and tooling stability on these
contracts while allowing our team to retain some flexibility. As I
mentioned on HipChat, I've often seen o.h.mapping as a Hibernate
internals only package (even as a user), and so exposing
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
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
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
