[hibernate-dev] JPA XML ORM descriptors id-class and id

[Gail Badner]

When an entity with an IdClass is mapped using XML ORM descriptors,
Hibernate requires the Id properties to be mapped as well, as in the
following example:



   
   
   
  
  
   


If the  elements are not included, an exception is thrown:

"No identifier specified for entity: ..."

Should Hibernate require the  elements to be explicitly mapped, or
should it be able to determine this information by reflection from the
class configured by ?

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

Re: [hibernate-dev] Hibernate Search 5.10.0.CR1 released!

[Guillaume Smet]

Better with the link:
http://in.relation.to/2018/05/09/hibernate-search-5-10-0-CR1/

Cheers.

On Tue, May 8, 2018 at 4:18 PM, Guillaume Smet  wrote:

> Hi,
>
> We just released the first release candidate of Hibernate Search 5.10 with
> support for Hibernate ORM 5.3.0.CR2 (and thus JPA 2.2).
>
> Test it and report any issues you might encounter!
>
> Thanks.
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.10.0.CR1 released!

[Guillaume Smet]

Hi,

We just released the first release candidate of Hibernate Search 5.10 with
support for Hibernate ORM 5.3.0.CR2 (and thus JPA 2.2).

Test it and report any issues you might encounter!

Thanks.

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

[hibernate-dev] Hibernate NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Here are the minutes of our NoORM IRC meeting:

5:52 < jbott> Meeting ended Tue May  8 13:52:19 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:52 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.html
15:52 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.txt
15:52 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.log.html

Cheers,

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

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Steve Ebersole]

>> Deferring initialization of these batch loaders is one option, but that
just really delays the memory consumption.  Personally, if it were my app
I'd rather that sizing be done up front rather than over the course of the
next few hours or weeks as the system continues to run.


Not sure how that is advocating that we delay the generation ;)

Anyway, that email thread is what led me to add the different batch modes.
That helps with the memory consumption (I think - I was waiting on someone
to test it).  Have you tried one of the alternative batch modes?  I think
DYNAMIC is the only one that will improve memory usage, however it incurs
the overhead of calculating the SQL each and every time.

I have always had the idea to come back and delay the creation of these.
IMO we could calculate the most likely used Loaders up-front
(LockMode.NONE, LockMode.READ) and delay the more less-used ones.  I think
this is part of the solution.

I think the bigger solution is along the lines of what Guillaume is
planning on looking at.  In fact this is one of the design aspects of 6.0.
Loader is designed to bind the SQL and the "load plan" into one
representation.  The problem here is that it is designed to do this by
doing both tasks internally - it templates building the SQL via its
JoinWalkers, which also builds the "load plan".  So both happen at the same
time as part of the  same process.  The real solution is to break this up
so that generation of the SQL and determination of the "load plan" can be
separate operations - namely so that we can share the "load plan" graph
with all of the nested loaders for a given batch loader (sharing the load
plan across all batch loaders for a given entity is not feasible - some
different fetch grapghs.

Anyway, like I said - this is one of the design goals with 6.0 and is
actually already in place there.

I think ultimately a combination of delayed (and then cached) generation of
these  and separately creatable and
passable "load plans" (especially in combination with batch strategies) is
the ultimate solution.  I'm just not sure how feasible the "separately
creatable and passable load plans" portion is in 5.x.  Hopefully Guillaume
has luck solving that one.



On Tue, May 8, 2018 at 7:27 AM Andrej Golovnin 
wrote:

> Hi Sanne,
>
> > sounds great. Do you plan to contribute your updated patch version?
>
> I don't think it is needed. I'm sure Guillaume will provide a good
> solution. And if not, then I will still have the best Hibernate
> version ever. :-) (OK, I will have in any case the best Hibernate
> version ever because I have more patches. But this is another story.
> :-) )
>
> Best regards,
> Andrej Golovnin
> ___
> 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] SingleTableEntityPersister memory footprint in 5.3

[Andrej Golovnin]

Hi Sanne,

> sounds great. Do you plan to contribute your updated patch version?

I don't think it is needed. I'm sure Guillaume will provide a good
solution. And if not, then I will still have the best Hibernate
version ever. :-) (OK, I will have in any case the best Hibernate
version ever because I have more patches. But this is another story.
:-) )

Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Sanne Grinovero]

Hi Andrej,

sounds great. Do you plan to contribute your updated patch version?

Thanks,
Sanne

On 8 May 2018 at 12:06, Andrej Golovnin  wrote:
> Hi Sanne,
>
>> you're right, I found the most interesting email from you now (reading
>> the whole thread) :
>>  - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html
>>
>> I'm not sure why the discussion stopped, I'm sorry.
>> Let's try to fix it this time, to make sure of that we need a JIRA.
>> Someone created one? Guillaume?
>>
>> summary:
>>  - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
>>  - great results applying Andrej's
>> https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
>>  - the patch could be improved today with Java8
>>-- I'd like to have some degree of upfront validation at boostrap still
>>-- hopefully explore an array based structure
>>-- do not extend CHM
>>-- ideally have no read barriers at all at runtime
>>
>
> This is an old patch. The current version does not extend CHM and even
> does not use it. It adds ca. 30 lines of code and modifies two classes
> to achieve the most memory savings.
>
> And Sanne, it is not needed to be sorry. Thanks to GIT I can apply my
> patches to the new version of Hibernate without big problems and have
> the best Hibernate version ever. :-)
>
> Best regards,
> Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Guillaume Smet]

Hi,

On Tue, May 8, 2018 at 11:42 AM, Sanne Grinovero 
wrote:

> I'm not sure why the discussion stopped, I'm sorry.
> Let's try to fix it this time, to make sure of that we need a JIRA.
> Someone created one? Guillaume?
>

No, I didn't. I plan to work on it tomorrow (today is a public holiday
here... and well Thursday too so I have my Friday booked for it too) and
will create the appropriate JIRAs once I have a good grasp of what needs to
be done.

Lazy loading the loaders is one thing but I think we should also try to
reduce the amount of memory consumed by them. Otherwise you can still have
the same issue under load. And it might be even more problematic as you
don't see the issue at startup.

As mentioned, I'll get back to you soon.

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

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Andrej Golovnin]

Hi Sanne,

> you're right, I found the most interesting email from you now (reading
> the whole thread) :
>  - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html
>
> I'm not sure why the discussion stopped, I'm sorry.
> Let's try to fix it this time, to make sure of that we need a JIRA.
> Someone created one? Guillaume?
>
> summary:
>  - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
>  - great results applying Andrej's
> https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
>  - the patch could be improved today with Java8
>-- I'd like to have some degree of upfront validation at boostrap still
>-- hopefully explore an array based structure
>-- do not extend CHM
>-- ideally have no read barriers at all at runtime
>

This is an old patch. The current version does not extend CHM and even
does not use it. It adds ca. 30 lines of code and modifies two classes
to achieve the most memory savings.

And Sanne, it is not needed to be sorry. Thanks to GIT I can apply my
patches to the new version of Hibernate without big problems and have
the best Hibernate version ever. :-)

Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK 11 Early Access build 12 available

[Rory O'Donnell]

Thanks Sanne !


On 08/05/2018 10:14, Sanne Grinovero wrote:
> Hi Rory,
>
> thanks for the regular updates!
>
> Unfortunately many tools we need are still unable to run properly on
> JDK11 so I can't run our comprehensive tests.
>
> For the record, a common issue seems to be the inability to parse the
> '11-ea' version number.
>
> The few modules I can run "manually" in isolation didn't highlight any
> specific problem with Hibernate libraries so far, but such testing has
> been quite limited. I hope to be able to tell you more soon.
>
> Regards,
> Sanne
>
>
>
>
> On 8 May 2018 at 09:05, Rory O'Donnell  wrote:
>> Hi Sanne,
>>
>>
>> **JDK 11 EA build 12 , *under both the GPL and Oracle EA licenses,
>> is now available at **http://jdk.java.net/11**. **
>> *
>>
>>* Newly approved Schedule, status & features
>>o http://openjdk.java.net/projects/jdk/11/
>>* Release Notes:
>>o http://jdk.java.net/11/release-notes
>>* Summary of changes
>>o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>>
>> *Notable changes in JDK 11 EA builds since last email:*
>>
>>* Build 11 - see Release Notes for details.
>>o JDK-8201315 : SelectableChannel.register may be invoked while a
>>  selection operation is in progress
>>* Build 10 - see Release Notes for details.
>>o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>>o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
>>o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>>* Build 9: - see Release Notes for details.
>>o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>>o JDK-8200458 : Readiness information previously recorded in
>>  SelectionKey ready set not preserved
>>
>> **
>>
>>
>> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
>> *
>> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
>> the JDK. As outlined in the JEP, the usefulness of this technology
>> have diminishing returns, the components using them are being removed
>> and connectivity speeds have improved by leaps and bounds,
>> since its inception.  Feedback appreciated via
>> http://mail.openjdk.java.net/pipermail/jdk-dev
>>
>> Regards,
>> Rory
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
>> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>>
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin,Ireland
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

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

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Sanne Grinovero]

Hi Andrej,

you're right, I found the most interesting email from you now (reading
the whole thread) :
 - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html

I'm not sure why the discussion stopped, I'm sorry.
Let's try to fix it this time, to make sure of that we need a JIRA.
Someone created one? Guillaume?

summary:
 - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
 - great results applying Andrej's
https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
 - the patch could be improved today with Java8
   -- I'd like to have some degree of upfront validation at boostrap still
   -- hopefully explore an array based structure
   -- do not extend CHM
   -- ideally have no read barriers at all at runtime

Thanks,
Sanne


On 6 May 2018 at 22:03, Andrej Golovnin  wrote:
> Hi,
>
>> So, I analyzed the dumps yesterday evening. The problem is real, meaning
>> his SessionFactory is consuming more than 1GB of memory for 600+ tables,
>> some with a lot of attributes. So for sure, the model is a big one, …
>
> No, it is still a small one. I work on a project with 2145 tables. And the 
> SessionFactory
> consumes on production systems ca 300-400MB with Hibernate 5.2. I haven’t
> tested the project with Hibernate 5.3. But I doubt it would consume more 
> memory.
> Except the Hibernate team broke something again.
>
>> but it
>> would be nice to be more gentle with this type of configuration. I don't
>> think it's something new to 5.3 though as it's not the first time we have
>> this type of reports.
>>
>>> From my observations, the problem mostly comes from:
>> LegacyBatchingEntityLoader
>> \_ loaders - EntityLoader
>> \_ staticLoadQuery - EntityLoadQueryDetails
>> \_ rootReturn - EntityReturnImpl
>>
>> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
>> MB.
>>
>> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
>> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
>> taking ~ 200 KB.
>>
>> We discussed some ideas yesterday with Steve.
>
> And I have discussed it with the Hibernate team 6 years ago:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html
>
> And my suggestion to create things lazily were ignored/rejected.
> And I have ignored the opinion of the Hibernate team and implemented
> my suggestions in my version of Hibernate and saved a lot of memory
> in my project.
>
> Btw. please ask the user whether he has a lot of abstract entity classes.
> When yes, then ask him if it would be possible to convert this entity classes
> to mapped supper-classes. This may help to reduce memory consumption too.
>
> Best regards,
> Andrej Golovnin

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

[hibernate-dev] PTO

[andrea boriero]

This afternoon I will be on PTO. Sorry for the late notice but it was due
to an unexpected event.

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

Re: [hibernate-dev] JDK 11 Early Access build 12 available

[Sanne Grinovero]

Hi Rory,

thanks for the regular updates!

Unfortunately many tools we need are still unable to run properly on
JDK11 so I can't run our comprehensive tests.

For the record, a common issue seems to be the inability to parse the
'11-ea' version number.

The few modules I can run "manually" in isolation didn't highlight any
specific problem with Hibernate libraries so far, but such testing has
been quite limited. I hope to be able to tell you more soon.

Regards,
Sanne




On 8 May 2018 at 09:05, Rory O'Donnell  wrote:
> Hi Sanne,
>
>
> **JDK 11 EA build 12 , *under both the GPL and Oracle EA licenses,
> is now available at **http://jdk.java.net/11**. **
> *
>
>   * Newly approved Schedule, status & features
>   o http://openjdk.java.net/projects/jdk/11/
>   * Release Notes:
>   o http://jdk.java.net/11/release-notes
>   * Summary of changes
>   o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>
> *Notable changes in JDK 11 EA builds since last email:*
>
>   * Build 11 - see Release Notes for details.
>   o JDK-8201315 : SelectableChannel.register may be invoked while a
> selection operation is in progress
>   * Build 10 - see Release Notes for details.
>   o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>   o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
>   o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>   * Build 9: - see Release Notes for details.
>   o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>   o JDK-8200458 : Readiness information previously recorded in
> SelectionKey ready set not preserved
>
> **
>
>
> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
> *
> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
> the JDK. As outlined in the JEP, the usefulness of this technology
> have diminishing returns, the components using them are being removed
> and connectivity speeds have improved by leaps and bounds,
> since its inception.  Feedback appreciated via
> http://mail.openjdk.java.net/pipermail/jdk-dev
>
> Regards,
> Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin,Ireland
>
> ___
> 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] JDK 11 Early Access build 12 available

[Rory O'Donnell]

Hi Sanne,


**JDK 11 EA build 12 , *under both the GPL and Oracle EA licenses, 
is now available at **http://jdk.java.net/11**. **
*

  * Newly approved Schedule, status & features
  o http://openjdk.java.net/projects/jdk/11/
  * Release Notes:
  o http://jdk.java.net/11/release-notes
  * Summary of changes
  o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html

*Notable changes in JDK 11 EA builds since last email:*

  * Build 11 - see Release Notes for details.
  o JDK-8201315 : SelectableChannel.register may be invoked while a
selection operation is in progress
  * Build 10 - see Release Notes for details.
  o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
  o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
  o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
  * Build 9: - see Release Notes for details.
  o JDK-8200152 : KerberosString uses UTF-8 encoding by default
  o JDK-8200458 : Readiness information previously recorded in
SelectionKey ready set not preserved

**


*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in 
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed 
and connectivity speeds have improved by leaps and bounds,
since its inception.  Feedback appreciated via 
http://mail.openjdk.java.net/pipermail/jdk-dev

Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752

Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

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

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Andrej Golovnin]

Hi Guillaume,

>> > It's not only the number of tables but also the number of columns per
>> > table.
>> > The table I take as an example in my tests has 200+ columns, which
>> > definitely doesn't help.
>>
>> I have also a lot of tables with high number of columns. The biggest
>> one has 254 columns. So what?
>
>
> So it's not the average 20 columns table.
>
> Not saying it's not a case we should be grateful with.
>
> --
> Guillaume
>

What you should really do is write a generator that would generate
models with a configurable number of entities, abstract entities,
mapped supper-classes, embeddables, relationships, fields, and so on.
You could integrate it into the build process to verify memory
consumption after every change in the Hibernate code. This would allow
you to find problems before you ship a new version of Hibernate.

It should be a good job for a student. :-)

Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev