[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi!

Here are the minutes of today's NoORM meeting:

15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
about MeetBot at
   http://wiki.debian.org/MeetBot . (v 0.1.4)
15:48 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
15:48 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
15:48 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html

Cheers,

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

HI,

I think I'll have to make it a little bit more clear in the docs as well. I
Knew about Hibernate comments and assumed they could be used as hints.

Now, that I look back on the Query API I see they were added in 4.3:

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Query.html#addQueryHint(java.lang.String)

But I can't find it in 4.2:

http://docs.jboss.org/hibernate/orm/4.2/javadocs/org/hibernate/Query.html

I will adjust my PR accordingly so that the comment on @NamedQuery will
only be propagated if the associated Hibernate property is set.
As for @NamedNativeQuery, I think we need to support it since we have the
comment attribute on the annotation level.

Vlad

On Tue, Aug 1, 2017 at 6:16 PM, Steve Ebersole  wrote:

> See inline..
>
> On Tue, Aug 1, 2017 at 9:05 AM Vlad Mihalcea 
> wrote:
>
>> I created a new Pull Request so that comments can be handled for named
>> queries (even for UPDATE/DELETE queries):
>>
>> https://github.com/hibernate/hibernate-orm/pull/1970
>>
>
> Not really following this.  See `org.hibernate.annotations.NamedQuery#comment`
> and `org.hibernate.annotations.QueryHints#COMMENT`.  So we do support
> this for named queries.  Hints are generally only useful (if at all) for
> SELECTs.  Comments can be useful for any type of statement, but again we
> have the support for those in place in regards to named queries.
>
>
> I think we should add two new issues;
>>
>> 1. So that we could pass Query Hints for Named (Native) Queries as well.
>> Right now we can only pass comments which are appended at the beginning of
>> the SQL statement.
>>
>
> I completely disagree about supporting comments and/or hints for native
> SQL queries.
>
> As for "[we only support] comments which are appended at the beginning of
> the SQL statement" - that is true for comments.  However, it is inaccurate
> for hints - see `org.hibernate.dialect.Dialect#getQueryHintString`.  So
> the hook is in place for handling this for hints.  There is no such hook
> for comments - do you concretely know of a Dialect that supports a comment
> elsewhere than the start?  I'm a little leery of adding support for this
> pre-6.0 as we know for certain that this will change (String-based versus
> AST-based).  If you wan to add such a hook in 6.0, I am ok with that -
> provided you can show me such a concrete use case.
>
>
>
>
>> 2. I see we support Query Hints for Oracle and SQL Server. We should
>> support MySQL as well:
>>
>> https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html
>>
>
> Sure - I think its a good idea to support this where ever  the underlying
> database supports it.
>
>
> If you have time to take a look on the PR, let me know what you think.
>>
>
> I'll take a look at the PR after we resolve these general points and they
> are incorporated into the PR.
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] CI Updates

[Davide D'Alto]

Hello,
I'm going to update Jenkins next Monday, I'll do my best to keep the
downtime to a minimum but,
because there are several plugins to update, I expect some disruption.
I'll do my best to keep it at a minimum

The exact date is going to be the 6th of August.

Thanks,
Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Steve Ebersole]

Actually the spec is quite specific on the expected behavior of these lock
modes, although it is very detailed and verbose almost to the point of
being unclear.

Also it is confusing to think of this in terms of generalized concepts such
as "exclusive" versus "non-exclusive".  Database locking across vendors is
not so binary.  Again, the JPA spec sets forth the expected outcomes.

If these outcomes can be (very) succinctly described then it could be a
good idea to cover them in the docs.  Otherwise, I think we should just
point to the JPA spec.  But if we do add it to the docs, we should avoid
explaining this via terms like "exclusive", etc. - just describe the
outcomes/phenomena.

On Tue, Aug 1, 2017 at 9:23 AM Vlad Mihalcea 
wrote:

> Sure. Send me a Pull Request and I'll integrate it.
>
> Vlad
>
> On Tue, Aug 1, 2017 at 2:29 PM, Arnold Gálovics 
> wrote:
>
> > Hey Vlad,
> >
> > Thanks for the clarification. Do you think it worth mentioning this in
> the
> > docs?
> >
> > Best,
> > Arnold
> >
> > On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea 
> > wrote:
> >
> >> In MVCC, shared and exclusive are not as significant as in 2PL
> >> concurrency control which only SQL Server supports by default nowadays.
> >>
> >> Even if the row is locked in shared or exclusive mode, some other DB
> will
> >> still read it. It's just that they will not be able to modify it or
> >> acquire locks. Here, if you acquire a shared lock, others will still be
> >> able to acquire a shared lock as well, and that will offer no advantage
> for
> >> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
> >>
> >> So, I suppose the lock should always be exclusive so that other lock
> >> requests are blocked until the lock is released.
> >>
> >> Vlad
> >>
> >> On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics <
> >> galovicsarn...@gmail.com> wrote:
> >>
> >>> Hey,
> >>>
> >>> I'm still a bit uncertain about this, as I only tested this lock mode
> >>> with H2 which as far as I know is not supporting shared locks, so it
> will
> >>> automatically acquire an exclusive lock. That is a possibility why I've
> >>> seen the FOR UPDATE clause at the end of the SELECT statement.
> >>>
> >>> *My question rather is:* what's the intended behavior of this lock
> >>> mode?
> >>> Okay, it's a pessimistic lock with incrementing the version number
> >>> automatically at locking time. What type of lock will it acquire?
> Shared or
> >>> exclusive?
> >>> I think this is important and it should be really mentioned in the
> >>> Hibernate docs as now it's a bit confusing. The JPA spec is also
> unclear
> >>> for me about this lock mode.
> >>>
> >>> Thank you guys for helping me out!
> >>>
> >>> Best Regards,
> >>> Arnold
> >>>
> >>>
> >>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> >>> wrote:
> >>>
>  That's how Hibernate was executing the statements when I wrote the
>  article.
> 
>  I spotted the difference when writing the book, but didn't have time
> to
>  update the article.
>  I changed the SQL output to reflect the current behavior which adds a
>  FOR UPDATE clause when fetching the entity.
> 
>  I also rephrased that sentence since it's no longer relevant to the
>  current behavior.
> 
>  Vlad
> 
>  On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
>  galovicsarn...@gmail.com> wrote:
> 
> > Hi all,
> >
> > I'm a bit confused with the mentioned lock mode.
> >
> > *The doc says the following:*
> > *"The entity is locked pessimistically and its version is incremented
> > automatically even if the entity has not changed."*
> >
> > I'm checking this with an H2 DB and the current behavior is the
> > following:
> > - the version attribute is incremented in advance, right after
> fetching
> > (I'm using EntityManager#find here, but with lock, it should be the
> > same)
> > - the original fetching query contains the SELECT ... FOR UPDATE
> clause
> >
> > Knowing this, it seems for me that this lock mode involves a DB lock,
> > however the doc doesn't say anything about this, especially whether
> > it's a
> > shared or exclusive lock.
> >
> > I've checked Vlad's article about this.
> > https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
> > ns-how-does-pessimistic_force_increment-lock-mode-work/
> >
> > It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
> > lead
> > you into thinking that you are using a pessimistic locking strategy,
> > while
> > in reality this Lock Mode is just an optimistic locking variation."*
> >
> > So now I'm unsure what this really is.
> >
> > Could you please briefly describe it to me if I missed something?
> >
> > Thanks in advance!
> >
> > Best Regards,
> > Arnold
> > 

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

I created a new Pull Request so that comments can be handled for named
queries (even for UPDATE/DELETE queries):

https://github.com/hibernate/hibernate-orm/pull/1970

I think we should add two new issues;

1. So that we could pass Query Hints for Named (Native) Queries as well.
Right now we can only pass comments which are appended at the beginning of
the SQL statement.
2. I see we support Query Hints for Oracle and SQL Server. We should
support MySQL as well:

https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html

If you have time to take a look on the PR, let me know what you think.

Thanks

On Tue, Aug 1, 2017 at 4:28 PM, Steve Ebersole  wrote:

> They have different intentions and are potentially applied in different
> ways for different databases - hence separate.
>
> E.g. DB2 supports a query comment, but does not support optimizer hints...
> so these need to be handled differently
>
> On Tue, Aug 1, 2017, 8:19 AM Vlad Mihalcea 
> wrote:
>
>> I'm asking because the
>>
>> org.hibernate.annotations.NamedNativeQuery or
>> org.hibernate.annotations.NamedQuery
>>
>> define the comment attribute with the following Javadoc:
>>
>> /**
>>  * A comment added to the generated SQL query.  Useful when engaging with 
>> DBA.
>>  */
>> String comment() default "";
>>
>> So, Hibernate clients could use the comment attribute in order to supply
>> an Oracle query hint, right?
>>
>> In this case, should we treat this attribute as a query hint so that the
>> Oracle/SQL Server hint logic applies to this one as well?
>>
>> Vlad
>>
>> On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole 
>> wrote:
>>
>>> Query hints are hints for the database' s query parser/optimizer.
>>>
>>> A comment is a... well a comment :)
>>>
>>> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea 
>>> wrote:
>>>
 Hi,

 While working on integrating a Pull Request, I realized that the
 org.hibernate.engine.spi.QueryParameters provides these two attributes:

 private String comment;
 private List queryHints;

 Both these two are to be sent to the database, so why do we have both?

 I also noticed that only for Query Hints we do take into consideration
 DB
 specific query hint syntax:

 // Keep this here, rather than moving to Select.  Some Dialects may
 need the hint to be appended to the very
 // end or beginning of the finalized SQL statement, so wait until
 everything is processed.
 if ( parameters.getQueryHints() != null &&
 parameters.getQueryHints().size() > 0 ) {
sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
 }

 Shouldn't we only have either comment or queryHints? Or what is the
 difference between these two?

 Vlad
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Steve Ebersole]

They have different intentions and are potentially applied in different
ways for different databases - hence separate.

E.g. DB2 supports a query comment, but does not support optimizer hints...
so these need to be handled differently

On Tue, Aug 1, 2017, 8:19 AM Vlad Mihalcea  wrote:

> I'm asking because the
>
> org.hibernate.annotations.NamedNativeQuery or
> org.hibernate.annotations.NamedQuery
>
> define the comment attribute with the following Javadoc:
>
> /**
>  * A comment added to the generated SQL query.  Useful when engaging with DBA.
>  */
> String comment() default "";
>
> So, Hibernate clients could use the comment attribute in order to supply
> an Oracle query hint, right?
>
> In this case, should we treat this attribute as a query hint so that the
> Oracle/SQL Server hint logic applies to this one as well?
>
> Vlad
>
> On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole 
> wrote:
>
>> Query hints are hints for the database' s query parser/optimizer.
>>
>> A comment is a... well a comment :)
>>
>> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea 
>> wrote:
>>
>>> Hi,
>>>
>>> While working on integrating a Pull Request, I realized that the
>>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>>
>>> private String comment;
>>> private List queryHints;
>>>
>>> Both these two are to be sent to the database, so why do we have both?
>>>
>>> I also noticed that only for Query Hints we do take into consideration DB
>>> specific query hint syntax:
>>>
>>> // Keep this here, rather than moving to Select.  Some Dialects may
>>> need the hint to be appended to the very
>>> // end or beginning of the finalized SQL statement, so wait until
>>> everything is processed.
>>> if ( parameters.getQueryHints() != null &&
>>> parameters.getQueryHints().size() > 0 ) {
>>>sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>>> }
>>>
>>> Shouldn't we only have either comment or queryHints? Or what is the
>>> difference between these two?
>>>
>>> Vlad
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Vlad Mihalcea]

Sure. Send me a Pull Request and I'll integrate it.

Vlad

On Tue, Aug 1, 2017 at 2:29 PM, Arnold Gálovics 
wrote:

> Hey Vlad,
>
> Thanks for the clarification. Do you think it worth mentioning this in the
> docs?
>
> Best,
> Arnold
>
> On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea 
> wrote:
>
>> In MVCC, shared and exclusive are not as significant as in 2PL
>> concurrency control which only SQL Server supports by default nowadays.
>>
>> Even if the row is locked in shared or exclusive mode, some other DB will
>> still read it. It's just that they will not be able to modify it or
>> acquire locks. Here, if you acquire a shared lock, others will still be
>> able to acquire a shared lock as well, and that will offer no advantage for
>> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>>
>> So, I suppose the lock should always be exclusive so that other lock
>> requests are blocked until the lock is released.
>>
>> Vlad
>>
>> On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics <
>> galovicsarn...@gmail.com> wrote:
>>
>>> Hey,
>>>
>>> I'm still a bit uncertain about this, as I only tested this lock mode
>>> with H2 which as far as I know is not supporting shared locks, so it will
>>> automatically acquire an exclusive lock. That is a possibility why I've
>>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>>
>>> *My question rather is:* what's the intended behavior of this lock
>>> mode?
>>> Okay, it's a pessimistic lock with incrementing the version number
>>> automatically at locking time. What type of lock will it acquire? Shared or
>>> exclusive?
>>> I think this is important and it should be really mentioned in the
>>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>>> for me about this lock mode.
>>>
>>> Thank you guys for helping me out!
>>>
>>> Best Regards,
>>> Arnold
>>>
>>>
>>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea 
>>> wrote:
>>>
 That's how Hibernate was executing the statements when I wrote the
 article.

 I spotted the difference when writing the book, but didn't have time to
 update the article.
 I changed the SQL output to reflect the current behavior which adds a
 FOR UPDATE clause when fetching the entity.

 I also rephrased that sentence since it's no longer relevant to the
 current behavior.

 Vlad

 On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
 galovicsarn...@gmail.com> wrote:

> Hi all,
>
> I'm a bit confused with the mentioned lock mode.
>
> *The doc says the following:*
> *"The entity is locked pessimistically and its version is incremented
> automatically even if the entity has not changed."*
>
> I'm checking this with an H2 DB and the current behavior is the
> following:
> - the version attribute is incremented in advance, right after fetching
> (I'm using EntityManager#find here, but with lock, it should be the
> same)
> - the original fetching query contains the SELECT ... FOR UPDATE clause
>
> Knowing this, it seems for me that this lock mode involves a DB lock,
> however the doc doesn't say anything about this, especially whether
> it's a
> shared or exclusive lock.
>
> I've checked Vlad's article about this.
> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
> ns-how-does-pessimistic_force_increment-lock-mode-work/
>
> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
> lead
> you into thinking that you are using a pessimistic locking strategy,
> while
> in reality this Lock Mode is just an optimistic locking variation."*
>
> So now I'm unsure what this really is.
>
> Could you please briefly describe it to me if I missed something?
>
> Thanks in advance!
>
> Best Regards,
> Arnold
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

I'm asking because the

org.hibernate.annotations.NamedNativeQuery or
org.hibernate.annotations.NamedQuery

define the comment attribute with the following Javadoc:

/**
 * A comment added to the generated SQL query.  Useful when engaging with DBA.
 */
String comment() default "";

So, Hibernate clients could use the comment attribute in order to supply an
Oracle query hint, right?

In this case, should we treat this attribute as a query hint so that the
Oracle/SQL Server hint logic applies to this one as well?

Vlad

On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole  wrote:

> Query hints are hints for the database' s query parser/optimizer.
>
> A comment is a... well a comment :)
>
> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> While working on integrating a Pull Request, I realized that the
>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>
>> private String comment;
>> private List queryHints;
>>
>> Both these two are to be sent to the database, so why do we have both?
>>
>> I also noticed that only for Query Hints we do take into consideration DB
>> specific query hint syntax:
>>
>> // Keep this here, rather than moving to Select.  Some Dialects may
>> need the hint to be appended to the very
>> // end or beginning of the finalized SQL statement, so wait until
>> everything is processed.
>> if ( parameters.getQueryHints() != null &&
>> parameters.getQueryHints().size() > 0 ) {
>>sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>> }
>>
>> Shouldn't we only have either comment or queryHints? Or what is the
>> difference between these two?
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Steve Ebersole]

Query hints are hints for the database' s query parser/optimizer.

A comment is a... well a comment :)

On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea  wrote:

> Hi,
>
> While working on integrating a Pull Request, I realized that the
> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>
> private String comment;
> private List queryHints;
>
> Both these two are to be sent to the database, so why do we have both?
>
> I also noticed that only for Query Hints we do take into consideration DB
> specific query hint syntax:
>
> // Keep this here, rather than moving to Select.  Some Dialects may
> need the hint to be appended to the very
> // end or beginning of the finalized SQL statement, so wait until
> everything is processed.
> if ( parameters.getQueryHints() != null &&
> parameters.getQueryHints().size() > 0 ) {
>sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
> }
>
> Shouldn't we only have either comment or queryHints? Or what is the
> difference between these two?
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Arnold Gálovics]

Hey Vlad,

Thanks for the clarification. Do you think it worth mentioning this in the
docs?

Best,
Arnold

On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea 
wrote:

> In MVCC, shared and exclusive are not as significant as in 2PL
> concurrency control which only SQL Server supports by default nowadays.
>
> Even if the row is locked in shared or exclusive mode, some other DB will
> still read it. It's just that they will not be able to modify it or
> acquire locks. Here, if you acquire a shared lock, others will still be
> able to acquire a shared lock as well, and that will offer no advantage for
> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>
> So, I suppose the lock should always be exclusive so that other lock
> requests are blocked until the lock is released.
>
> Vlad
>
> On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics  > wrote:
>
>> Hey,
>>
>> I'm still a bit uncertain about this, as I only tested this lock mode
>> with H2 which as far as I know is not supporting shared locks, so it will
>> automatically acquire an exclusive lock. That is a possibility why I've
>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>
>> *My question rather is:* what's the intended behavior of this lock mode?
>> Okay, it's a pessimistic lock with incrementing the version number
>> automatically at locking time. What type of lock will it acquire? Shared or
>> exclusive?
>> I think this is important and it should be really mentioned in the
>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>> for me about this lock mode.
>>
>> Thank you guys for helping me out!
>>
>> Best Regards,
>> Arnold
>>
>>
>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea 
>> wrote:
>>
>>> That's how Hibernate was executing the statements when I wrote the
>>> article.
>>>
>>> I spotted the difference when writing the book, but didn't have time to
>>> update the article.
>>> I changed the SQL output to reflect the current behavior which adds a
>>> FOR UPDATE clause when fetching the entity.
>>>
>>> I also rephrased that sentence since it's no longer relevant to the
>>> current behavior.
>>>
>>> Vlad
>>>
>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
>>> galovicsarn...@gmail.com> wrote:
>>>
 Hi all,

 I'm a bit confused with the mentioned lock mode.

 *The doc says the following:*
 *"The entity is locked pessimistically and its version is incremented
 automatically even if the entity has not changed."*

 I'm checking this with an H2 DB and the current behavior is the
 following:
 - the version attribute is incremented in advance, right after fetching
 (I'm using EntityManager#find here, but with lock, it should be the
 same)
 - the original fetching query contains the SELECT ... FOR UPDATE clause

 Knowing this, it seems for me that this lock mode involves a DB lock,
 however the doc doesn't say anything about this, especially whether
 it's a
 shared or exclusive lock.

 I've checked Vlad's article about this.
 https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
 ns-how-does-pessimistic_force_increment-lock-mode-work/

 It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
 lead
 you into thinking that you are using a pessimistic locking strategy,
 while
 in reality this Lock Mode is just an optimistic locking variation."*

 So now I'm unsure what this really is.

 Could you please briefly describe it to me if I missed something?

 Thanks in advance!

 Best Regards,
 Arnold
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

Hi,

While working on integrating a Pull Request, I realized that the
org.hibernate.engine.spi.QueryParameters provides these two attributes:

private String comment;
private List queryHints;

Both these two are to be sent to the database, so why do we have both?

I also noticed that only for Query Hints we do take into consideration DB
specific query hint syntax:

// Keep this here, rather than moving to Select.  Some Dialects may
need the hint to be appended to the very
// end or beginning of the finalized SQL statement, so wait until
everything is processed.
if ( parameters.getQueryHints() != null &&
parameters.getQueryHints().size() > 0 ) {
   sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
}

Shouldn't we only have either comment or queryHints? Or what is the
difference between these two?

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK 9 build 180 support

[Davide D'Alto]

Thanks Guillaume,

I've already copied the latest build on CI but the Job are still using
the previous one.

Can I make the switch?

On Mon, Jul 31, 2017 at 7:21 PM, Guillaume Smet
 wrote:
> Hi,
>
> To support the latest JDK 9, you need to upgrade the enforcer and javadoc
> plugins to 3.0.0-M1.
>
> See:
> https://github.com/hibernate/hibernate-validator/pull/822/commits/e94ecc1d05ed75dbd37bc000b337917dc7c23b17
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev