Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #381
by Steve Ebersole
Anyone know why this test continues to fail intermittently?
---------- Forwarded message ----------
From: "Hibernate CI" <ci(a)hibernate.org>
Date: Nov 19, 2013 6:44 PM
Subject: Build failed in Jenkins: hibernate-orm-master-h2 #381
To: <steve(a)hibernate.org>
Cc:
See <http://ci.hibernate.org/job/hibernate-orm-master-h2/381/changes>
Changes:
[Steve Ebersole] HHH-8720 - Create an index for the topical guides
[Steve Ebersole] HHH-8692 - Document value generation feature
------------------------------------------
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building in workspace <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
Fetching changes from the remote Git repository
Fetching upstream changes from git://github.com/hibernate/hibernate-orm.git
Checking out Revision 4e6f3a975357cda4519df8972f5be95cf7ff0745
(origin/master)
[workspace] $ /bin/sh -xe /tmp/hudson1245240517042988452.sh
+ ./gradlew clean test check :release:aggregateJavadocs publish
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
Creating properties on demand (a.k.a. dynamic properties) has been
deprecated and is scheduled to be removed in Gradle 2.0. Please read
http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraProperties...
information on the replacement for dynamic properties.
Deprecated dynamic property: "exportPackageVersion" on "project
':documentation'", value: "4.3.0".
Deprecated dynamic property "exportPackageVersion" created in multiple
locations.
The ConfigurationContainer.add() method has been deprecated and is
scheduled to be removed in Gradle 2.0. Please use the create() method
instead.
The TaskContainer.add() method has been deprecated and is scheduled to be
removed in Gradle 2.0. Please use the create() method instead.
:documentation:clean UP-TO-DATE
:hibernate-c3p0:clean
:hibernate-core:clean
:hibernate-ehcache:clean
:hibernate-entitymanager:clean
:hibernate-envers:clean
:hibernate-gradle-plugin:clean
:hibernate-infinispan:clean
:hibernate-jpamodelgen:clean
:hibernate-maven-plugin:clean
:hibernate-osgi:clean
:hibernate-proxool:clean
:hibernate-testing:clean
:release:clean
:documentation:compileJava UP-TO-DATE
:documentation:processResources UP-TO-DATE
:documentation:classes UP-TO-DATE
:documentation:compileTestJava UP-TO-DATE
:documentation:processTestResources UP-TO-DATE
:documentation:testClasses UP-TO-DATE
:documentation:test UP-TO-DATE
:hibernate-c3p0:copyJavaApiSignature
:hibernate-core:copyJavaApiSignature
:hibernate-core:generateGrammarSource
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
:hibernate-core:jaxb
:hibernate-core:generateMainLoggingClasses
:hibernate-core:compileJavawarning: [options] bootstrap class path not set
in conjunction with -source 1.6
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-core:processResources
:hibernate-core:classes
:hibernate-core:jar
:hibernate-c3p0:generateMainLoggingClasses
:hibernate-c3p0:compileJavawarning: [options] bootstrap class path not set
in conjunction with -source 1.6
1 warning
:hibernate-c3p0:processResources
:hibernate-c3p0:classes
:hibernate-testing:copyJavaApiSignature
:hibernate-testing:generateMainLoggingClasses
:hibernate-testing:compileJavawarning: [options] bootstrap class path not
set in conjunction with -source 1.6
Note: <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/...>
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-testing:processResources UP-TO-DATE
:hibernate-testing:classes
:hibernate-testing:jar
:hibernate-c3p0:compileTestJavawarning: [options] bootstrap class path not
set in conjunction with -source 1.6
Note: <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/src...>
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 warning
:hibernate-c3p0:processTestResources
:hibernate-c3p0:testClasses
:hibernate-c3p0:test
:hibernate-c3p0:checkstyleMain
:hibernate-c3p0:findbugsMain
FindBugs rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/tar...
>
:hibernate-c3p0:findbugsTest
:hibernate-c3p0:buildDashboard
:hibernate-core:generateTestGrammarSource UP-TO-DATE
:hibernate-core:compileTestJavawarning: [options] bootstrap class path not
set in conjunction with -source 1.6
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-core:processTestResources
:hibernate-core:testClasses
:hibernate-core:test
:hibernate-core:checkstyleMain
Checkstyle rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/tar...
>
:hibernate-core:findbugsMain
FindBugs rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/tar...
>
:hibernate-core:findbugsTest
FindBugs rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/tar...
>
:hibernate-core:buildDashboard
:hibernate-ehcache:copyJavaApiSignature
:hibernate-ehcache:generateMainLoggingClasses
:hibernate-ehcache:compileJavawarning: [options] bootstrap class path not
set in conjunction with -source 1.6
1 warning
:hibernate-ehcache:processResources
:hibernate-ehcache:classes
:hibernate-ehcache:compileTestJavawarning: [options] bootstrap class path
not set in conjunction with -source 1.6
Note: <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/...>
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-ehcache:processTestResources
:hibernate-ehcache:testClasses
:hibernate-ehcache:test
:hibernate-ehcache:checkstyleMain
:hibernate-ehcache:findbugsMain
FindBugs rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/...
>
:hibernate-ehcache:findbugsTest
FindBugs rule violations were found. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/...
>
:hibernate-ehcache:buildDashboard
:hibernate-entitymanager:copyJavaApiSignature
:hibernate-entitymanager:generateMainLoggingClasses
:hibernate-entitymanager:compileJavawarning: [options] bootstrap class path
not set in conjunction with -source 1.6
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-entitymanager:processResources
:hibernate-entitymanager:classes
:hibernate-jpamodelgen:copyJavaApiSignature
:hibernate-jpamodelgen:generateMainLoggingClasses
:hibernate-jpamodelgen:jaxb
:hibernate-jpamodelgen:compileJavawarning: [options] bootstrap class path
not set in conjunction with -source 1.6
warning: a package-info.java file has already been seen for package unnamed
package
warning: a package-info.java file has already been seen for package unnamed
package
warning: a package-info.java file has already been seen for package unnamed
package
warning: a package-info.java file has already been seen for package unnamed
package
5 warnings
:hibernate-jpamodelgen:processResources
:hibernate-jpamodelgen:classes
:hibernate-jpamodelgen:jar
:hibernate-entitymanager:generateTestJpaMetamodelClasses
:hibernate-entitymanager:compileTestJavawarning: [options] bootstrap class
path not set in conjunction with -source 1.6
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
:hibernate-entitymanager:copyBundleResources
:hibernate-entitymanager:processTestResources
:hibernate-entitymanager:testClasses
:hibernate-entitymanager:test
org.hibernate.jpa.test.lock.LockTest > testContendedPessimisticLock FAILED
javax.persistence.RollbackException at LockTest.java:387
394 tests completed, 1 failed, 8 skipped
:hibernate-entitymanager:test FAILED
:hibernate-entitymanager:buildDashboard
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':hibernate-entitymanager:test'.
> There were failing tests. See the report at: file://<
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entityma...
>
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.
BUILD FAILED
Total time: 25 mins 53.306 secs
Build step 'Execute shell' marked build as failure
[CHECKSTYLE] Skipping publisher since build result is FAILURE
[FINDBUGS] Skipping publisher since build result is FAILURE
[TASKS] Skipping publisher since build result is FAILURE
Recording test results
Publishing Javadoc
11 years
hot to avoid build error "OutOfMemoryError: PermGen space" for ":documentation:asciidoctor"
by Scott Marlow
Has anyone seen the below error doing a "./gradlew build
:release:distZip"?
Is there a way to skip building ":documentation:asciidoctor" during a
release?
Build error:
"
':documentation:asciidoctor'.
> Could not initialize class org.jruby.runtime.backtrace.FrameType
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.
BUILD FAILED
Total time: 1 hrs 9 mins 52.22 secs
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.gradle.launcher.bootstrap.EntryPoint.createCompleter(EntryPoint.java:61)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:52)
at org.gradle.launcher.Main.main(Main.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58)
Build step 'Execute shell' marked build as failure
"
11 years
Build failure buiding envers
by Gail Badner
:hibernate-envers:compileTestJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':hibernate-envers:compileTestJava'.
> java.lang.ClassCastException: com.sun.tools.javac.code.Symbol$TypeSymbol cannot be cast to javax.lang.model.element.TypeElement
Regards,
Gail
11 years
Re: [hibernate-dev] SessionEventsListener feature (HHH-8654)
by Gunnar Morling
Yes, at least that seems to be the more common convention. I could find way
more classes named *EventListener than *EventsListener in my IDE and on
Google, and there are also examples of *EventListener types handling
several event types, e.g. javax.sql.ConnectionEventListener.
--Gunnar
2013/11/15 Steve Ebersole <steven.ebersole(a)gmail.com>
> Even though you have multiple event*s* being handled?
>
>
> On Thu 14 Nov 2013 06:20:09 AM CST, Sanne Grinovero wrote:
>
>> On 14 November 2013 11:36, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>>
>>> Hi,
>>>
>>> This sounds very promising.
>>>
>>> Regarding the suggested type names, I'd personally prefer
>>> SessionEventListener
>>> (without the plural "s") and something like BaseSessionEventListener
>>> instead of EmptySessionEventsListener, as "empty" implies a specific
>>> behavior which a sub-class would not satisfy when overriding methods.
>>>
>>
>> +1
>> +1
>>
>> Sanne
>>
>>
>>> --Gunnar
>>>
>>>
>>>
>>>
>>> 2013/11/13 Steve Ebersole <steve(a)hibernate.org>
>>>
>>> I wanted to highlight a new feature in 4.3 as it came about from
>>>> performance testing efforts. Its a way to hopefully help track down
>>>> potential performance problems in applications that use Hibernate. In
>>>> this way it is similar to statistics, but it operates per-Session
>>>> (though certainly custom impls could role the metrics up to a SF level).
>>>>
>>>> It revolves around the SessionEventsListener[1] interface which
>>>> essentially defines a number of start/end pairs for the interesting
>>>> events (for example starting to prepare a JDBC statement and ending that
>>>> preparation).
>>>>
>>>> Multiple SessionEventsListener instances can be associated with the
>>>> Session simultaneously. You can add them programatically to a Session
>>>> using Session#addEventsListeners(SessionEventsListener...) method.
>>>> They
>>>> can also be added to the Session up-front via the
>>>> SessionFactory#withOptions API for building Sessions.
>>>>
>>>> Additionally there are 2 settings that allow SessionEventsListener impls
>>>> to be applied to all Sessions created:
>>>>
>>>> * 'hibernate.session.events.auto' allows you to name any arbitrary
>>>> SessionEventsListener class to apply to all Sessions.
>>>> * 'hibernate.session.events.log' refers to a particular built-in
>>>> implementation of SessionEventsListener that applies some timings across
>>>> the start/end pairs
>>>> (org.hibernate.engine.internal.LoggingSessionEventsListener). In fact
>>>> this listener is added by default if (a) stats are enabled and (b) the
>>>> log level (currently INFO) of LoggingSessionEventsListener is enabled.
>>>> Below[2] is some sample output of LoggingSessionEventsListener.
>>>>
>>>> There is also a org.hibernate.EmptySessionEventsListener (no-op) class
>>>> to help develop custom ones.
>>>>
>>>> Anyway, as much as anything I wanted to point it out so people can try
>>>> it out and to get feedback. I think the API covers most of the
>>>> interesting events. If you feel there are any missing, lets discuss
>>>> here or on a Jira issue.
>>>>
>>>>
>>>> [1] https://gist.github.com/sebersole/7438250
>>>>
>>>> [2]
>>>> 14:40:20,017 INFO LoggingSessionEventsListener:275 - Session Metrics {
>>>> 9762 nanoseconds spent acquiring 1 JDBC connections;
>>>> 0 nanoseconds spent releasing 0 JDBC connections;
>>>> 1020726 nanoseconds spent preparing 4 JDBC statements;
>>>> 1442351 nanoseconds spent executing 4 JDBC statements;
>>>> 0 nanoseconds spent executing 0 JDBC batches;
>>>> 0 nanoseconds spent executing 0 L2C puts;
>>>> 0 nanoseconds spent executing 0 L2C hits;
>>>> 0 nanoseconds spent executing 0 L2C misses;
>>>> 2766689 nanoseconds spent executing 1 flushes (flushing a total of
>>>> 3 entities and 1 collections);
>>>> 1096552384585007 nanoseconds spent executing 2 partial-flushes
>>>> (flushing a total of 3 entities and 3 collections)
>>>> }
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
11 years
[OGM] Support of the MongoDB aggregation framework
by Guillaume SCHEIBEL
Hello,
I'm (at the moment) listening to the "MongoDB for JPA developers) and the
speaker talks about the aggregation framework. Should we plan to support it
as well ?
I think a eventual way would be by adding a DSL next to the MongoDBDialect
?
What do you think ?
Guillaume
11 years
[OGM] public repositories and snapshot version
by Guillaume SCHEIBEL
Hi guys,
How often is the snapshot version of ogm published onto the public
repositories ? (btw which one is "valid" [1] ? [2] ? other? ).
I asking that because I worked with Arun and the Java EE 7 sample to have
an OGM integration (and it's working with the Ehcache module) and we need
to have access to the current version (which is 4.0.0-SNAPSHOT), I went on
the 2 repos mentioned above and on both the release dates back to January
and that's quite old.
Other question, shouldn't we release a new version like Beta5 specially now
we have the Neo4j support ?
Last but not least, why the version on the README.md and the pom.xml are
not the same (respectively 4.0.0.Beta4 and 4.0.0-SNAPSHOT).
Cheers,
Guillaume
11 years
Tuning ORM memory consumption [HHH-8682]
by Sanne Grinovero
Hi all,
from some performance tests we learned that a bottleneck for Hibernate
using applications is often identified in the amount of memory we
allocate at runtime, even considering the so called "short lived"
objects which usually are not a threat are actually too high.
Specifically, the highest consumer is the wild high amount of
instances of _org.hibernate.engine.spi.EntityKey_.
I think we have mainly two different strategies to attack this:
1# reduce the amount of EntityKey instances being allocated
2# reduce the size of each EntityKey instance
While 1# seems a wise move, I'll leave that to the ORM experts to
consider for future as it probably requires a broader knowledge of how
all components fit together.
So I'm attacking 2#, especially as I thought I could get some high win
in short time :)
To properly estimate the runtime size of each instance, I could simply
use the various reference tables of how much each pointer and
primitive takes, but there is actually some more complexity related to
the order in which the fields will be organized, and the requirement
of object alignment.
The rules aren't too hard to figure out the cost of a small value
object, but I'm actually using a tool which nicely dumps out a
reasonable estimate: "java object layout".
So this is the output of the current EntityKey implementation:
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
org.hibernate.engine.spi.EntityKey
offset size type description
0 12 (assumed to be the object
header + first field alignment)
12 4 int EntityKey.hashCode
16 1 boolean EntityKey.isBatchLoadable
17 3 (alignment/padding gap)
20 4 Serializable EntityKey.identifier
24 4 String EntityKey.entityName
28 4 String EntityKey.rootEntityName
32 4 String EntityKey.tenantId
36 4 Type EntityKey.identifierType
40 4 SessionFactoryImplementor EntityKey.factory
44 4 (loss due to the next object alignment)
48 (object boundary, size estimate)
So that's 48 bytes per instance, and matches my expectations.
In our benchmark, we created about 200GB of such instances in 20
minutes, and the impact is of approximately 10% of the overall memory
pressure of the application.
I have an open pull request [2] which improves things, changing the
code to the following layout:
org.hibernate.engine.spi.EntityKey
offset size type description
0 12 (assumed to be the object header +
first field alignment)
12 4 int EntityKey.hashCode
16 4 Serializable EntityKey.identifier
20 4 String EntityKey.tenantId
24 4 EntityEssentials EntityKey.persister
28 4 (loss due to the next object alignment)
32 (object boundary, size estimate)
So we get from 48 to 32 bytes per instance; assuming the same
allocation that means saving about 33%, so some 60GB of memory
bandwith saved.
I think we could take it as a first step in the right direction, still
we're so very close to actually improve of 50%: there are 4 bytes per
instance "wasted" just because of alignment needs, if we could remove
just one more field we would save 8bytes.
In this example I removed the _tenantId_:
org.hibernate.engine.spi.EntityKey
offset size type description
0 12 (assumed to be the object header +
first field alignment)
12 4 int EntityKey.hashCode
16 4 Serializable EntityKey.identifier
20 4 EntityEssentials EntityKey.persister
24 (object boundary, size estimate)
So I would aim at implementing this, or alternatively if we really
can't remove the tenantId we could remove the (cached) hashCode:
org.hibernate.engine.spi.EntityKey
offset size type description
0 12 (assumed to be the object header +
first field alignment)
12 4 Serializable EntityKey.identifier
16 4 String EntityKey.tenantId
20 4 EntityEssentials EntityKey.persister
24 (object boundary, size estimate)
But that hashCode calculation is really hot so I would love to rather
remove the _tenantId_.
How can we remove the tenantId ?
I was thinking to have the tenandId included in the persister, so we'd
have a new interface:
public interface TenantLocalEntityPersister extends EntityPersister {
String getTenantId();
}
Implementors would have two fields:
EntityPersister ep; //shared across all tenants
String tenantId;
Then one single instance of such a TenantLocalEntityPersister would be
shared across all EntityKey instances associated to it, but also by
many other objects which need to shrink: for example
org.hibernate.engine.spi.EntityEntry needs to access the same concept,
and is the second highest consumer of memory (so next in line for a
similar refactoring to be done).
Would that be doable to refactor EntityPersister to have this concept
of per-tenant instance?
As a nice side-effect, I suspect it would also bring the cost of
managing multi-tenancy to zero for those applications which aren't
doing any multi-tenancy, while now there seems to be a cost paid by
all users.
Sanne
[1] https://github.com/jbaruch/java-object-layout
[2] https://github.com/hibernate/hibernate-orm/pull/633
11 years
