hi all, perhaps somebody can explain me what is happening in the background
I have an EAR which was deployable without problems on 24.0.1 / javaEE 8
after upgrade to jakartaee 10 / hibernate 6.2.2 / PostgreSQL DB the app can’t deployed in any why problem is the deployment time its running for hours and then the memory is increasing until OOM (at the moment 10G / and 30min for timeout)
what I want to understand ist why is this statement running in all comibinations for the Entities and its associations
07:42:19,484 DEBUG [org.hibernate.orm.sql.ast.create] (ServerService Thread Pool – 23) Created new SQL alias : c66813_0
07:42:19,496 DEBUG [org.hibernate.orm.sql.ast.create] (ServerService Thread Pool – 23) Registration of TableGroup [org.hibernate.sql.ast.tree.from.LazyTableGroup@7e43af3c] with identifierForTableGroup
[treat(treat(treat(treat(treat(treat(treat(
my.commission.CommissionBaseElem.commission.vendorCommission.brokerage as
#my.price.pricecomposition.ComplexPriceLineElem).toValue as
#my.price.pricecomposition.ComplexPriceLineElem).fromValue.costPool.realEstateCharge.realEstate.legalBasis as
#my.legal.at.RealEstateATLegalBasisElem).energyExam.issuer as #my.contact.ContactElem).currentDsgvo as
#my.crm.dsgvo.DSGVoRequestElem).executor.person.primaryAddress as
#my.address.ComplexAddressElem).secondaryAddress as my.address.ValidatedAddressElem).city.district.state.country.countryMetaData]
for NavigablePath [treat(treat(treat(treat(treat(treat(treat(
my.commission.CommissionBaseElem.commission.vendorCommission.brokerage as
#my.price.pricecomposition.ComplexPriceLineElem).toValue as
#my.price.pricecomposition.ComplexPriceLineElem).fromValue.costPool.realEstateCharge.realEstate.legalBasis as
#my.legal.RealEstateATLegalBasisElem).energyExam.issuer as
#my.contact.ContactElem).currentDsgvo as #my.crm.dsgvo.DSGVoRequestElem).executor.person.primaryAddress as
#my.address.ComplexAddressElem).secondaryAddress as my.address.ValidatedAddressElem).city.district.state.country.countryMetaData]
App has about 400 Entities
Domain Info on associations / but ast.create takes ALL and not only a path
CommissionBaseElem.commmission [OneToOne/BI] CommissionElem.vendorCommission [OneToOne/UNI] CommissionBlockElem.brokerage [OneToOne/UNI] PriceLineElem(ComplexPrixeLine).toValue…
[
… And really ALL depth is analysed for ALL combies…
what I’m doing wrong or is this a bug / feature ?
br horst
Can you share a bit of your entity model?
You should definitely read the migration guide entries:
Chances are, you define associations as eager everywhere and have a few self referential associations which cause big queries to be generated internally.
hi,
thank’s for answer, read all spec and still searching for changes…
as defined in the Spec before a ToOne was on LAZY always depending on the persistence provider and default is EAGER (this I can’t find in JakartaEE 10 anymore…)
second wir are working on GRAPHs which can have cycles included, and if not from the domain model loosely coupled these are now real problems, in this direction my question is going why the AST is going on all combinations really ALL in all depths without reusing subpaths of join trees.
these subpaths are in real world a can be but not a must, which means not all paths will exist on querying. (but associations exist)
according the Domain Model Part (in this case Pricing / Address are generic parts which are reused on multiple places) is there a different possibility that you get it… I don’t want to offer a wide view on my system…
br horst
I don’t know your domain model, but you should really read this section as this might be the change that is causing you trouble.
as defined in the Spec before a ToOne was on LAZY always depending on the persistence provider and default is EAGER (this I can’t find in JakartaEE 10 anymore…)
I don’t know where you read this. @ManyToOne and @OneToOne have always been FetchType.EAGER by default and the recommendation from our side is to always use FetchType.LAZY. Avoid FetchType.EAGER at all cost and model fetching through entity graphs or join fetches instead.
second wir are working on GRAPHs which can have cycles included, and if not from the domain model loosely coupled these are now real problems, in this direction my question is going why the AST is going on all combinations really ALL in all depths without reusing subpaths of join trees.
If your domain is a graph, then you are most likely running into the problem I linked. Just make sure that your self-referential associations all use FetchType.LAZY.
hi
yes but this
@ManyToOne(fetch = FetchType.LAZY) or @OneToOne(fetch = FetchType.LAZY)
was before not possible because of the provider specific implementation
especially for @OneToOne with proxy or null which ends in a bidirectional association ALWAYS in EAGER as it was before
is this now different, as it seems yes but how is a bidirectional then handled ?! or should MapIds be used ?
(see also)
thanx for your help… (I just want to understand it… before it was working without additional configuration …)
was before not possible because of the provider specific implementation
I don’t know what you are referring to, LAZY always worked for Hibernate. If you are talking about the handling for @OneToOne(mappedBy = "..."), then yes, even if you use LAZY, Hibernate will join that association because it needs to do that, to determine if the field should be initialized to null or a proxy. With bytecode enhancement you can defer the initialization to the first access of the field.