Re: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ? [HHH-11253]

[Sanne Grinovero]

On 23 February 2018 at 20:29, Steve Ebersole  wrote:
> You mean change to 5.3?  +1

Right that's what I meant. Thanks, will do!

>
> On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero  wrote:
>>
>> HHH-11253 is about making ByteBuddy the default implementation, but
>> it's flagged for 6.
>>
>> I think that in Paris there was consensus to make it the default in
>> 5.3 alredy, to possibly drop Javassist entirely in 6.0.
>>
>> May I change this to 6 ? If that's ok, I can assign it to myself.
>>
>> Thanks,
>> Sanne
>> ___
>> 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] Hibernate ORM 5.2.14.Final has been released

[andrea boriero]

*For
details:http://in.relation.to/2018/02/27/hibernate-orm-5214-final-release
*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Here are the minutes of our biweekly NoORM IRC meeting:

15:42 < jbott> Meeting ended Tue Feb 27 14:42:36 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:42 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.html
15:42 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.txt
15:42 < jbott> Log:

http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.log.html

Cheers,

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

Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?

[Gail Badner]

Steve,

I ran into a snag when fixing this.

Please take a look at my pull request:
https://github.com/hibernate/hibernate-orm/pull/2167

Thanks,
Gail

On Thu, Feb 1, 2018 at 5:39 AM, Vlad Mihalcea 
wrote:

> Hi Gail,
>
> Steve is right. Database locks cannot be released unless you end the
> transaction and that's how it works on any RDBMS, either in 2PL Mode or
> MVCC.
>
> As for optimistic locks:
>
> 1. LockModeType.OPTIMISTIC
>
> The check is done at the end of the end of the transaction. Refresh will
> only update the version, but the check should still be done so we should
> not probably switch to LockModeTypeNONE.
>
> 2. OPTIMISTIC_FORCE_INCREMENT,
>
> This one triggers a version increment in a different entity, so it should
> not be affected by the refresh of our entity.
>
> Vlad
>
> On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner  wrote:
>
>> OK, sounds good.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole 
>> wrote:
>>
>> > It is possible to call EntityManager#lock(Object entity, LockModeType
>> >> lockMode) with a lower-level lock, but that request will be ignored.
>> >> Hibernate will only upgrade a lock.
>> >>
>> >
>> > Sure, this is in keeping with most (all?) databases - a transaction can
>> > only acquire more restrictive locks.
>> >
>> >
>> >
>> >> I think that clarifies retaining the same lock-level for the entity
>> when
>> >> calling EntityManager#refresh(Object entity).
>> >>
>> >> If no one has any comments that disagree with this in the next couple
>> of
>> >> days, I'll go with that.
>> >>
>> >
>> > That's the correct handling.
>> >
>> >
>> ___
>> 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