SessionFactory in QueryKey

Description

I guess that after improvement HHH-5138, a ManyToOneType.java (and many other types) has reference to SessionFactory (by TypeFactory.TypeScope scope field). And now QueryKey, which contains Type[] positionalParameterTypes field, contains also SessionFactory - eg. ManyToOneType. So now we can find SessionFactory in QueryCache elements, which unnecessarily increase memory usage. There is another problem when cache replication is used (ehcache via RMI), I've got an exception during SessionFactory deserialization in receiver node:

Apr 27 06:17:58 WARN net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator:320 - Unable to send message to remote peer. Message was: null
Apr 27 06:17:58 java.lang.NullPointerException
Apr 27 06:17:58 at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Apr 27 06:17:58 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Apr 27 06:17:58 at java.lang.reflect.Method.invoke(Method.java:597)
Apr 27 06:17:58 at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480)
Apr 27 06:17:58 at org.hibernate.cache.QueryKey.readObject(QueryKey.java:192)

Activity

Christian BeikovApril 8, 2022 at 3:27 PM

Since no test case was provided for years, I'll close this issue as out of date. I also believe it will most probably not be an issue any more in 6.0.
If this still is an issue for you, please create a new issue with a test case that reproduces the problem.

Steve EbersoleOctober 28, 2015 at 3:24 AM

As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.

Steve EbersoleOctober 27, 2015 at 7:17 PM

This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.

For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/

Pawel OmelkoSeptember 26, 2011 at 6:34 AM

Hi Julian,

Just name your sessionFactory using hibernate.session_factory_name property. When you do that, your SF instance will be added to NAMED_INSTANCES hashMap, in every clusters node. So when cache will be replicated and deserialized in another node, SF won't be deserialized but taken from NAMED_INSTANCES map. It's working.

Relu DutaSeptember 23, 2011 at 6:51 PM

I am having the same problem even with 3.5.

This is a serious issue for people using @EmbeddedId or any other org.hibernate.type.ComponentType PK with remote caches since the SessionFactory does not exist on the remote JVM and it's not needed either.

Can you guys suggest a solution to bypass this functionality? How can naming the SF solve this since the remote JVM has no JNDI context.

Thanks!

Out of Date

Details

Assignee

Reporter

Labels

Priority

Created April 27, 2011 at 8:40 AM
Updated April 8, 2022 at 3:27 PM
Resolved April 8, 2022 at 3:27 PM