[Hibernate-JIRA] Created: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
5:17 a.m.
Implementations of org.hibernate.type.Type contain references to non-serializable
entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it in
the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a reference
to the comparator, but does not enforce its serializability. It should at least throw a
runtime exception in org.hibernate.mapping.Collection::getComparator if the comparator is
not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:53 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Mindaugas Žakšauskas commented on HHH-6880:
-------------------------------------------
Just noticed one more:
4) org.hibernate.type.ComponentType.tuplizerMapping should probably be declared as
transient - as it is not used neither in .equals(Object) nor in .isEqual(Object, Object,
EntityMode). From what I can see, these are the only two methods that are relevant for 2nd
level cache (at least for Ehcache) as it needs to check the equalness of CacheKey when
flushing it on the remote end.
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
Labels: hibernate
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:55 a.m.
New subject: [Hibernate-JIRA] Issue Comment Edited: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Mindaugas Žakšauskas edited comment on HHH-6880 at 12/7/11 8:53 AM:
--------------------------------------------------------------------
Just noticed one more:
4) org.hibernate.type.ComponentType.tuplizerMapping should probably be declared as
transient - as it is not used in .equals(Object) nor in .isEqual(Object, Object,
EntityMode). From what I can see, these are the only two methods that are relevant for 2nd
level cache (at least for Ehcache) as it needs to check the equalness of CacheKey when
flushing it on the remote end.
was (Author: mindas):
Just noticed one more:
4) org.hibernate.type.ComponentType.tuplizerMapping should probably be declared as
transient - as it is not used neither in .equals(Object) nor in .isEqual(Object, Object,
EntityMode). From what I can see, these are the only two methods that are relevant for 2nd
level cache (at least for Ehcache) as it needs to check the equalness of CacheKey when
flushing it on the remote end.
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
Labels: hibernate
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:57 a.m.
New subject: [Hibernate-JIRA] Issue Comment Edited: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Mindaugas Žakšauskas edited comment on HHH-6880 at 12/7/11 8:57 AM:
--------------------------------------------------------------------
<previous comment was invalid, ignore it>
was (Author: mindas):
Just noticed one more:
4) org.hibernate.type.ComponentType.tuplizerMapping should probably be declared as
transient - as it is not used in .equals(Object) nor in .isEqual(Object, Object,
EntityMode). From what I can see, these are the only two methods that are relevant for 2nd
level cache (at least for Ehcache) as it needs to check the equalness of CacheKey when
flushing it on the remote end.
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
Labels: hibernate
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:11 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole commented on HHH-6880:
-------------------------------------
When you mention that types hold reference to {{Session}}, I assume you just mistyped and
meant to say {{SessionFactory}}...
Do you have a test case actually showing this?
It would seem that directly serializing/deserializing a {{SessionFactory}} is not doing
what I remembered it does. What I thought happened while serializing/deserializing a
{{SessionFactory}} actually only happens when the {{SessionFactory}} ser/deser happens as
part of {{SessionImpl}} ser/deser.
Seems like we just missed having {{org.hibernate.internal.SessionFactoryImpl#writeObject}}
call {{org.hibernate.internal.SessionFactoryImpl#serialize}} and
{{org.hibernate.internal.SessionFactoryImpl#readObject}} call
{{org.hibernate.internal.SessionFactoryImpl#deserialize}}
Could you test out those changes? Otherwise this will have to wait for a later release.
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
Labels: hibernate
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:13 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole updated HHH-6880:
--------------------------------
Fix Version/s: 4.0.2
Labels: serialization (was: hibernate)
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Priority: Critical
Labels: serialization
Fix For: 4.0.2
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:36 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole updated HHH-6880:
--------------------------------
Assignee: Steve Ebersole
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Fix For: 4.0.1
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:32 p.m.
New subject: [Hibernate-JIRA] Closed: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole closed HHH-6880.
-------------------------------
Resolution: Incomplete
Fix Version/s: (was: 4.0.1)
Actually, I missed the fact that {{SessionFactoryImpl}} additionally implements
{{#readResolve}}.
What is (most likely) missing in your code is naming the {{SessionFactory}}. The linked
issue simply allows that to happen without that name having to be a JNDI name. Just name
your {{SessionFactory}}. If you do not want this published into JNDI, then disable the
new setting discussed on HHH-6822
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:14 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Mindaugas Žakšauskas commented on HHH-6880:
-------------------------------------------
Q: When you mention that types hold reference to Session, I assume you just mistyped and
meant to say SessionFactory...
A: Yes, my bad. I meant {{o.h.e.SessionFactoryImplementor}} interface and its
implementation, {{o.h.i.SessionFactoryImpl}}.
Q: Do you have a test case actually showing this?
A: Not really, as the real world scenario involves two different hosts and fat layer of
configuration (including caching). It is however quite evident if you look at the source
code of {{o.h.t.ComponentType}} or the others I mentioned.
I appreciate your efforts trying to solve this, but I don't think this solution is
good enough. Reasons:
- We do not want to bind {{SessionFactory}} to JNDI and the option for avoiding this is
only available in Hibernate v4. For most enterprises, upgrading such a major library to a
.0 version is not really an option.
- You have not commented on my proposition to remove {{ComponentType.typeScope}} (and
others) or at least make it {{transient}}. If an attribute is not used at all, why bother
with serialization of something that is totally unnecessary? For the scenario which is
driven by this issue (serializing cache keys and sending them over the network), speed is
the key!!!
- You have not responded/haven't done any action with regards to the last issue I
mentioned (comparator at {{org.hibernate.type.SortedSetType}} and
{{org.hibernate.type.SortedMapType}}).
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:25 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole commented on HHH-6880:
-------------------------------------
{quote}
Q: Do you have a test case actually showing this?
A: Not really, as the real world scenario involves two different hosts and fat layer of
configuration (including caching). It is however quite evident if you look at the source
code of o.h.t.ComponentType or the others I mentioned.
{quote}
That is not accurate. Just look at the test I wrote for the linked HHH-6822
{quote}
We do not want to bind SessionFactory to JNDI and the option for avoiding this is only
available in Hibernate v4. For most enterprises, upgrading such a major library to a .0
version is not really an option.
{quote}
Nor apparently did you even look at the linked HHH-6822 :) You do not have to bind it to
JNDI.
As for the others, I don't think they really require response. Something is getting
serialized that should not; plain and simple. So the fix was to not serialize it, or to
serialize it in the correct manner.
Again, try looking at HHH-6822
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:29 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole commented on HHH-6880:
-------------------------------------
And I totally do not understand:
{quote}
upgrading such a major library to a .0 version is not really an option.
{quote}
The mentioned changed (HHH-6822) will be included in 4.0.1 which is a bug fix release. If
you don't upgrade major libraries for point releases god have mercy on your soul...
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:13 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Mindaugas Žakšauskas commented on HHH-6880:
-------------------------------------------
Steve: Just look at the test I wrote for the linked HHH-6822
MZ: The unit test ({{SessionFactorySerializationTest}}) tests whether {{SessionFactory}}
is correctly serialized. That's fine. My point was that {{o.h.t.ComponentType}} (and
others) should not even *attempt* to serialize {{typeScope}} (which is of type
{{o.h.t.TypeFactory.TypeScope}} and which contains reference to {{SessionFactory}}). Why
serialize something what not used when deserialized (in fact, it is +*not used at all*+,
but that's another matter)? In our system we need to replicate billions of Hibernate
cache flush events over the network, and each unnecessary transferred byte just adds to
the delay to the overall system consistency.
Steve: If you don't upgrade major libraries for point releases god have mercy on your
soul...
MZ: 4.0.1 is a bugfix release to 4.0.0. We are running 3.6.7 and do not plan to upgrade to
4.X for a while. Correct me if I'm wrong, but as I understand 4.X is a major upgrade
over 3.X.
Steve: as for the others, I don't think they really require response.
MZ: are you saying that having references to non-serializable objects (comparators) is OK
in a serializable class ({{org.hibernate.type.SortedSetType}})?
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:28 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=c...
]
Steve Ebersole commented on HHH-6880:
-------------------------------------
{quote}
are you saying that having references to non-serializable objects (comparators) is OK in a
serializable class
{quote}
The comparator associated with a sorted set is specified by the user. The comparators
implemented by Hibernate are in fact serializable. We cannot control what a user might
hand us. It seems reasonable that if they want to serialize Hibernate objects that hold
references to their classes, that they in turn make those objects serialzable.
There will be no more 3.6 releases. No more 3.x release at all. Really your problem is
that you say you are stuck on 3.6. All this other discussion is moot.
Implementations of org.hibernate.type.Type contain references to
non-serializable entities
------------------------------------------------------------------------------------------
Key: HHH-6880
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7
Environment: Seen this on MySQL but I believe this is environment-agnostic
Reporter: Mindaugas Žakšauskas
Assignee: Steve Ebersole
Priority: Critical
Labels: serialization
Time Spent: 59m
This is a spin-off from
-
https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8...
- http://stackoverflow.com/q/8404559/7345
org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g.
to flush a cache on a different cluster node when a certain object has been updated.
The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes)
happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
This problem is actually not just theoretic but also causes real pain. First, it takes
much longer to broadcast cache flush events. Secondly, I get this exception during
deserialization of such a CacheKey:
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at
org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
at my.class.deserializeKey(EhcacheUtils.java:35)
I have done a quick scan through all the types, and found these problems related to their
serializability:
1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of
both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is
assigned in the constructor and kept in the but seems to be never used. The typeScope in
turn has a reference to the SessionImpl. Can it simply be removed?
2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it
in the getter, so I guess it should be safe to remove it, too.
3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a
reference to the comparator, but does not enforce its serializability. It should at least
throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the
comparator is not serializable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4548
days inactive
4575
days old
hibernate-issues@lists.jboss.org
12 comments
2 participants
participants (2)
-
Mindaugas Žakšauskas (JIRA) -
Steve Ebersole (JIRA)