Re: [hibernate-dev] SQL Server lock hints misunderstanding

2017-03-23 Thread Vlad Mihalcea
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 )

Re: [hibernate-dev] SQL Server lock hints misunderstanding

2017-03-23 Thread Steve Ebersole
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

Re: [hibernate-dev] SQL Server lock hints misunderstanding

2017-03-23 Thread Chris Cranford
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_,

Re: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes

2017-03-23 Thread Chris Cranford
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

Re: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes

2017-03-23 Thread Sanne Grinovero
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

Re: [hibernate-dev] SQL Server lock hints misunderstanding

2017-03-23 Thread Christian Beikov
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_,

[hibernate-dev] SQL Server lock hints misunderstanding

2017-03-23 Thread Vlad Mihalcea
--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,

Re: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes

2017-03-23 Thread andrea boriero
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