Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #70754 is a reply to message #70749] |
Wed, 07 February 2007 19:00   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Michael,
EObject implementations should not override equals or hashCode:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions of
the framework assume that there are no overrides and hence that == can
be used in place of .equals. If I could, I would do as suggested in
the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
> I've run into a problem with Teneo.
> Some of my EObjects implement hashCode/equals using the properties stored in
> the EObject.
> It appears that Teneo updates the IdentifierCacheHandler.idMap before any of
> the properties are set. The Key inserted into the idMap has a hashCode for
> an "empty" object. Once all the properties are set and Hibernate is
> retrieving the identity to see if it has changed, the Key used will not map
> to the original one since all the properties have been set. This leads to an
> exception similar to the following:
> org.hibernate.HibernateException: identifier of an instance of
> SomeModelObjectClass was altered from 1 to null
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
> at
> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
> at
> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>
> Is there any way to get around this issue without removing the
> hashCode/equals implementations in my EObjects?
> Thanks,
> -mike
>
>
>
|
|
| | |
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71013 is a reply to message #70834] |
Thu, 08 February 2007 12:16 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Martin,
So that's a good reason why making them final might be upsetting to
folks, but doing not following the EMF advice in an EMF context is
likely to break assumptions in EMF. Not only is writing a good
implementation of hashCode and equals far trickier than it should be but
having the hashCode depend on the state of the object makes it very
dangerous to ever make an EObject be the key of a map, since Java's map
implementations assume that the hashCode of a key does not change, and
if it does, the map is corrupted. There is no checking for this, so
it's likely to lead to horrible bugs. You could never, for example,
rely on using a WeakHashMap to associate data with mutable EObjects
(unless you derived your own from something like IdentityHashMap). So
in EMF, overriding equals and hashCode for EObjects is done at your own
risk...
Martin Taal wrote:
> Hi Ed,
> The override argument can also come from Hibernate: the hibernate
> manual explicitly states that for specific cases you should override
> hashcode and equals and let these methods use meaningfull information
> from the objects itself. So there are two frameworks with opposing
> guidelines.
>
> gr. Martin
>
> Ed Merks wrote:
>> Michael,
>>
>> EObject implementations should not override equals or hashCode:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions
>> of the framework assume that there are no overrides and hence that ==
>> can be used in place of .equals. If I could, I would do as
>> suggested in the bug and make these methods final in BasicEObjectImpl.
>>
>>
>> Michael Kanaley wrote:
>>> I've run into a problem with Teneo.
>>> Some of my EObjects implement hashCode/equals using the properties
>>> stored in the EObject.
>>> It appears that Teneo updates the IdentifierCacheHandler.idMap
>>> before any of the properties are set. The Key inserted into the
>>> idMap has a hashCode for an "empty" object. Once all the properties
>>> are set and Hibernate is retrieving the identity to see if it has
>>> changed, the Key used will not map to the original one since all the
>>> properties have been set. This leads to an exception similar to the
>>> following:
>>> org.hibernate.HibernateException: identifier of an instance of
>>> SomeModelObjectClass was altered from 1 to null
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>> at
>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>
>>>
>>> Is there any way to get around this issue without removing the
>>> hashCode/equals implementations in my EObjects?
>>> Thanks,
>>> -mike
>>>
>>>
>
>
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71695 is a reply to message #70854] |
Thu, 15 February 2007 10:15 |
 Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
Hi Martin,
I got around this issue simply by calling the following on each object
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message
news:eqdq4q$v95$1@utils.eclipse.org...
> Michael,
> Your issue with the IdentifierCacheHandler arises because the hashcode is
> different for an empty and a 'filled' object. So to solve this I would
> suggest that you change the hashcode method to be stable for both cases
> and for different objects which are equal. The contract for the hashcode()
> allows a fair amount of freedom for the implementation. Afaics the equals
> method does not need to change for the IdentifierCacheHandler (as it uses
> == anyway).
>
> The identifiercachehandler uses == equals logic because it uses a weakref
> and is really used to find the id for a loaded object from the db.
>
> Note that the identifiercachehandler is only used for so-called synthetic
> id's which are created automatically when there is no id attribute. Your
> issue should normally not arise if you have explicit id attributes.
>
> Overall I would also look at if you do not break any emf specifics as Ed
> pointed out.
>
> gr. Martin
>
> Ed Merks wrote:
>> Michael,
>>
>> EObject implementations should not override equals or hashCode:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions of
>> the framework assume that there are no overrides and hence that == can be
>> used in place of .equals. If I could, I would do as suggested in the
>> bug and make these methods final in BasicEObjectImpl.
>>
>>
>> Michael Kanaley wrote:
>>> I've run into a problem with Teneo.
>>> Some of my EObjects implement hashCode/equals using the properties
>>> stored in the EObject.
>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>> any of the properties are set. The Key inserted into the idMap has a
>>> hashCode for an "empty" object. Once all the properties are set and
>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>> used will not map to the original one since all the properties have been
>>> set. This leads to an exception similar to the following:
>>> org.hibernate.HibernateException: identifier of an instance of
>>> SomeModelObjectClass was altered from 1 to null
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>> at
>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>
>>> Is there any way to get around this issue without removing the
>>> hashCode/equals implementations in my EObjects?
>>> Thanks,
>>> -mike
>>>
>>>
>
>
> --
>
> With Regards, Martin Taal
>
> Springsite/Elver.org
> Office: Hardwareweg 4, 3821 BV Amersfoort
> Postal: Nassaulaan 7, 3941 EC Doorn
> The Netherlands
> Tel: +31 (0)84 420 2397
> Fax: +31 (0)84 225 9307
> Mail: mtaal@springsite.com - mtaal@elver.org
> Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71752 is a reply to message #71695] |
Thu, 15 February 2007 12:17 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Michael,
Thanks for the update, for my interest what is the summary object (is it equals to myObject)?
After it was loaded, you mean also before it was put in the IdentifierCacheHandler (with a wrong
hascode?)?
gr. Martin
Michael Kanaley wrote:
> Hi Martin,
> I got around this issue simply by calling the following on each object
> after it was loaded:
> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>
> The Hibernate Session holds the id value.
>
> -mike
>
> "Martin Taal" <mtaal@elver.org> wrote in message
> news:eqdq4q$v95$1@utils.eclipse.org...
>> Michael,
>> Your issue with the IdentifierCacheHandler arises because the hashcode is
>> different for an empty and a 'filled' object. So to solve this I would
>> suggest that you change the hashcode method to be stable for both cases
>> and for different objects which are equal. The contract for the hashcode()
>> allows a fair amount of freedom for the implementation. Afaics the equals
>> method does not need to change for the IdentifierCacheHandler (as it uses
>> == anyway).
>>
>> The identifiercachehandler uses == equals logic because it uses a weakref
>> and is really used to find the id for a loaded object from the db.
>>
>> Note that the identifiercachehandler is only used for so-called synthetic
>> id's which are created automatically when there is no id attribute. Your
>> issue should normally not arise if you have explicit id attributes.
>>
>> Overall I would also look at if you do not break any emf specifics as Ed
>> pointed out.
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Michael,
>>>
>>> EObject implementations should not override equals or hashCode:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions of
>>> the framework assume that there are no overrides and hence that == can be
>>> used in place of .equals. If I could, I would do as suggested in the
>>> bug and make these methods final in BasicEObjectImpl.
>>>
>>>
>>> Michael Kanaley wrote:
>>>> I've run into a problem with Teneo.
>>>> Some of my EObjects implement hashCode/equals using the properties
>>>> stored in the EObject.
>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>> any of the properties are set. The Key inserted into the idMap has a
>>>> hashCode for an "empty" object. Once all the properties are set and
>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>> used will not map to the original one since all the properties have been
>>>> set. This leads to an exception similar to the following:
>>>> org.hibernate.HibernateException: identifier of an instance of
>>>> SomeModelObjectClass was altered from 1 to null
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>> at
>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>
>>>> Is there any way to get around this issue without removing the
>>>> hashCode/equals implementations in my EObjects?
>>>> Thanks,
>>>> -mike
>>>>
>>>>
>>
>> --
>>
>> With Regards, Martin Taal
>>
>> Springsite/Elver.org
>> Office: Hardwareweg 4, 3821 BV Amersfoort
>> Postal: Nassaulaan 7, 3941 EC Doorn
>> The Netherlands
>> Tel: +31 (0)84 420 2397
>> Fax: +31 (0)84 225 9307
>> Mail: mtaal@springsite.com - mtaal@elver.org
>> Web: www.springsite.com - www.elver.org
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71827 is a reply to message #71752] |
Thu, 15 February 2007 18:25 |
Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for
myObject before any properties are set (it has the wrong hashCode). When my
application logic gets a hold of myObject (after all the properties of
myObject are set), I register another Key - the one that will actually be
used when commit is called. The Key registered by the Teneo library will
just hang out in the map until myObject is GC'ed - it is never used by Teneo
or the application.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message
news:er1j1h$cs6$1@utils.eclipse.org...
> Hi Michael,
> Thanks for the update, for my interest what is the summary object (is it
> equals to myObject)?
> After it was loaded, you mean also before it was put in the
> IdentifierCacheHandler (with a wrong hascode?)?
>
> gr. Martin
>
> Michael Kanaley wrote:
>> Hi Martin,
>> I got around this issue simply by calling the following on each object
>> after it was loaded:
>> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>>
>> The Hibernate Session holds the id value.
>>
>> -mike
>>
>> "Martin Taal" <mtaal@elver.org> wrote in message
>> news:eqdq4q$v95$1@utils.eclipse.org...
>>> Michael,
>>> Your issue with the IdentifierCacheHandler arises because the hashcode
>>> is different for an empty and a 'filled' object. So to solve this I
>>> would suggest that you change the hashcode method to be stable for both
>>> cases and for different objects which are equal. The contract for the
>>> hashcode() allows a fair amount of freedom for the implementation.
>>> Afaics the equals method does not need to change for the
>>> IdentifierCacheHandler (as it uses == anyway).
>>>
>>> The identifiercachehandler uses == equals logic because it uses a
>>> weakref and is really used to find the id for a loaded object from the
>>> db.
>>>
>>> Note that the identifiercachehandler is only used for so-called
>>> synthetic id's which are created automatically when there is no id
>>> attribute. Your issue should normally not arise if you have explicit id
>>> attributes.
>>>
>>> Overall I would also look at if you do not break any emf specifics as Ed
>>> pointed out.
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>> Michael,
>>>>
>>>> EObject implementations should not override equals or hashCode:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions
>>>> of the framework assume that there are no overrides and hence that ==
>>>> can be used in place of .equals. If I could, I would do as suggested
>>>> in the bug and make these methods final in BasicEObjectImpl.
>>>>
>>>>
>>>> Michael Kanaley wrote:
>>>>> I've run into a problem with Teneo.
>>>>> Some of my EObjects implement hashCode/equals using the properties
>>>>> stored in the EObject.
>>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>>> any of the properties are set. The Key inserted into the idMap has a
>>>>> hashCode for an "empty" object. Once all the properties are set and
>>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>>> used will not map to the original one since all the properties have
>>>>> been set. This leads to an exception similar to the following:
>>>>> org.hibernate.HibernateException: identifier of an instance of
>>>>> SomeModelObjectClass was altered from 1 to null
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>>> at
>>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>>
>>>>> Is there any way to get around this issue without removing the
>>>>> hashCode/equals implementations in my EObjects?
>>>>> Thanks,
>>>>> -mike
>>>>>
>>>>>
>>>
>>> --
>>>
>>> With Regards, Martin Taal
>>>
>>> Springsite/Elver.org
>>> Office: Hardwareweg 4, 3821 BV Amersfoort
>>> Postal: Nassaulaan 7, 3941 EC Doorn
>>> The Netherlands
>>> Tel: +31 (0)84 420 2397
>>> Fax: +31 (0)84 225 9307
>>> Mail: mtaal@springsite.com - mtaal@elver.org
>>> Web: www.springsite.com - www.elver.org
>>
>>
>
>
> --
>
> With Regards, Martin Taal
>
> Springsite/Elver.org
> Office: Hardwareweg 4, 3821 BV Amersfoort
> Postal: Nassaulaan 7, 3941 EC Doorn
> The Netherlands
> Tel: +31 (0)84 420 2397
> Fax: +31 (0)84 225 9307
> Mail: mtaal@springsite.com - mtaal@elver.org
> Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71847 is a reply to message #71827] |
Thu, 15 February 2007 18:40 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------010204020003090807000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Michael,
I wonder if this implies that the map will be incomplete every time your
object changes state in a way that affects hashCode?
Michael Kanaley wrote:
> Sorry,
> that should have read:
> IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
>
> The Teneo library is updating the IdentifierCacheHandler with a Key for
> myObject before any properties are set (it has the wrong hashCode). When my
> application logic gets a hold of myObject (after all the properties of
> myObject are set), I register another Key - the one that will actually be
> used when commit is called. The Key registered by the Teneo library will
> just hang out in the map until myObject is GC'ed - it is never used by Teneo
> or the application.
> -mike
>
> "Martin Taal" <mtaal@elver.org> wrote in message
> news:er1j1h$cs6$1@utils.eclipse.org...
>
>> Hi Michael,
>> Thanks for the update, for my interest what is the summary object (is it
>> equals to myObject)?
>> After it was loaded, you mean also before it was put in the
>> IdentifierCacheHandler (with a wrong hascode?)?
>>
>> gr. Martin
>>
>> Michael Kanaley wrote:
>>
>>> Hi Martin,
>>> I got around this issue simply by calling the following on each object
>>> after it was loaded:
>>> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>>>
>>> The Hibernate Session holds the id value.
>>>
>>> -mike
>>>
>>> "Martin Taal" <mtaal@elver.org> wrote in message
>>> news:eqdq4q$v95$1@utils.eclipse.org...
>>>
>>>> Michael,
>>>> Your issue with the IdentifierCacheHandler arises because the hashcode
>>>> is different for an empty and a 'filled' object. So to solve this I
>>>> would suggest that you change the hashcode method to be stable for both
>>>> cases and for different objects which are equal. The contract for the
>>>> hashcode() allows a fair amount of freedom for the implementation.
>>>> Afaics the equals method does not need to change for the
>>>> IdentifierCacheHandler (as it uses == anyway).
>>>>
>>>> The identifiercachehandler uses == equals logic because it uses a
>>>> weakref and is really used to find the id for a loaded object from the
>>>> db.
>>>>
>>>> Note that the identifiercachehandler is only used for so-called
>>>> synthetic id's which are created automatically when there is no id
>>>> attribute. Your issue should normally not arise if you have explicit id
>>>> attributes.
>>>>
>>>> Overall I would also look at if you do not break any emf specifics as Ed
>>>> pointed out.
>>>>
>>>> gr. Martin
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> EObject implementations should not override equals or hashCode:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299. Large portions
>>>>> of the framework assume that there are no overrides and hence that ==
>>>>> can be used in place of .equals. If I could, I would do as suggested
>>>>> in the bug and make these methods final in BasicEObjectImpl.
>>>>>
>>>>>
>>>>> Michael Kanaley wrote:
>>>>>
>>>>>> I've run into a problem with Teneo.
>>>>>> Some of my EObjects implement hashCode/equals using the properties
>>>>>> stored in the EObject.
>>>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>>>> any of the properties are set. The Key inserted into the idMap has a
>>>>>> hashCode for an "empty" object. Once all the properties are set and
>>>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>>>> used will not map to the original one since all the properties have
>>>>>> been set. This leads to an exception similar to the following:
>>>>>> org.hibernate.HibernateException: identifier of an instance of
>>>>>> SomeModelObjectClass was altered from 1 to null
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>>>> at
>>>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>>>
>>>>>> Is there any way to get around this issue without removing the
>>>>>> hashCode/equals implementations in my EObjects?
>>>>>> Thanks,
>>>>>> -mike
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>>
>>>> With Regards, Martin Taal
>>>>
>>>> Springsite/Elver.org
>>>> Office: Hardwareweg 4, 3821 BV Amersfoort
>>>> Postal: Nassaulaan 7, 3941 EC Doorn
>>>> The Netherlands
>>>> Tel: +31 (0)84 420 2397
>>>> Fax: +31 (0)84 225 9307
>>>> Mail: mtaal@springsite.com - mtaal@elver.org
>>>> Web: www.springsite.com - www.elver.org
>>>>
>>>
>> --
>>
>> With Regards, Martin Taal
>>
>> Springsite/Elver.org
>> Office: Hardwareweg 4, 3821 BV Amersfoort
>> Postal: Nassaulaan 7, 3941 EC Doorn
>> The Netherlands
>> Tel: +31 (0)84 420 2397
>> Fax: +31 (0)84 225 9307
>> Mail: mtaal@springsite.com - mtaal@elver.org
>> Web: www.springsite.com - www.elver.org
>>
>
>
>
--------------010204020003090807000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
I wonder if this implies that the map will be incomplete every time
your object changes state in a way that affects hashCode? <br>
<br>
<br>
Michael Kanaley wrote:
<blockquote cite="mider28jk$t73$1@utils.eclipse.org" type="cite">
<pre wrap="">Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for
myObject before any properties are set (it has the wrong hashCode). When my
application logic gets a hold of myObject (after all the properties of
myObject are set), I register another Key - the one that will actually be
used when commit is called. The Key registered by the Teneo library will
just hang out in the map until myObject is GC'ed - it is never used by Teneo
or the application.
-mike
"Martin Taal" <a class="moz-txt-link-rfc2396E" href="mailto:mtaal@elver.org"><mtaal@elver.org></a> wrote in message
<a class="moz-txt-link-freetext" href="news:er1j1h$cs6$1@utils.eclipse.org">news:er1j1h$cs6$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Michael,
Thanks for the update, for my interest what is the summary object (is it
equals to myObject)?
After it was loaded, you mean also before it was put in the
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Martin,
I got around this issue simply by calling the following on each object
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <a class="moz-txt-link-rfc2396E" href="mailto:mtaal@elver.org"><mtaal@elver.org></a> wrote in message
<a class="moz-txt-link-freetext" href="news:eqdq4q$v95$1@utils.eclipse.org">news:eqdq4q$v95$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode
is different for an empty and a 'filled' object. So to solve this I
would suggest that you change the hashcode method to be stable for both
cases and for different objects which are equal. The contract for the
hashcode() allows a fair amount of freedom for the implementation.
Afaics the equals method does not need to change for the
IdentifierCacheHandler (as it uses == anyway).
The identifiercachehandler uses == equals logic because it uses a
weakref and is really used to find the id for a loaded object from the
db.
Note that the identifiercachehandler is only used for so-called
synthetic id's which are created automatically when there is no id
attribute. Your issue should normally not arise if you have explicit id
attributes.
Overall I would also look at if you do not break any emf specifics as Ed
pointed out.
gr. Martin
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Michael,
EObject implementations should not override equals or hashCode:
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299">https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299</a>. Large portions
of the framework assume that there are no overrides and hence that ==
can be used in place of .equals. If I could, I would do as suggested
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've run into a problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before
any of the properties are set. The Key inserted into the idMap has a
hashCode for an "empty" object. Once all the properties are set and
Hibernate is retrieving the identity to see if it has changed, the Key
used will not map to the original one since all the properties have
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of
SomeModelObjectClass was altered from 1 to null
at
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
Is there any way to get around this issue without removing the
hashCode/equals implementations in my EObjects?
Thanks,
-mike
</pre>
</blockquote>
</blockquote>
<pre wrap="">--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <a class="moz-txt-link-abbreviated" href="mailto:mtaal@springsite.com">mtaal@springsite.com</a> - <a class="moz-txt-link-abbreviated" href="mailto:mtaal@elver.org">mtaal@elver.org</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.springsite.com">www.springsite.com</a> - <a class="moz-txt-link-abbreviated" href="http://www.elver.org">www.elver.org</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <a class="moz-txt-link-abbreviated" href="mailto:mtaal@springsite.com">mtaal@springsite.com</a> - <a class="moz-txt-link-abbreviated" href="mailto:mtaal@elver.org">mtaal@elver.org</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.springsite.com">www.springsite.com</a> - <a class="moz-txt-link-abbreviated" href="http://www.elver.org">www.elver.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------010204020003090807000403--
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #71909 is a reply to message #71847] |
Thu, 15 February 2007 22:26 |
Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_007D_01C75137.318A3220
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
These particular objects are never updated after they are created the =
first time so the hashcode won't change. If they did then you are =
certainly correct.
The reason had to bother with setting the IdentifierCacheHandler at all =
is that these objects were retrieved as a part of a transaction where =
other objects were getting updated. When the transaction was committed =
the hibernate logic was checking to see if any of the objects were =
dirty. Turns out that this calls Teneo's EntityPersister which indicated =
that the identity of these objects was null since the hashCode changed. =
This triggered Hibernate to think these objects were dirty and then =
threw an exception saying that it doesn't know how to deal with null =
identities.
Thanks for following up on this. I will certainly recommend to people in =
my organization not to override EObject's hashcode/equals methods.
-mike
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:er29fr$rf6$1@utils.eclipse.org...
Michael,
I wonder if this implies that the map will be incomplete every time =
your object changes state in a way that affects hashCode?=20
Michael Kanaley wrote:=20
Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for=20
myObject before any properties are set (it has the wrong hashCode). When =
my=20
application logic gets a hold of myObject (after all the properties of=20
myObject are set), I register another Key - the one that will actually =
be=20
used when commit is called. The Key registered by the Teneo library will =
just hang out in the map until myObject is GC'ed - it is never used by =
Teneo=20
or the application.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message=20
news:er1j1h$cs6$1@utils.eclipse.org...
Hi Michael,
Thanks for the update, for my interest what is the summary object (is it =
equals to myObject)?
After it was loaded, you mean also before it was put in the=20
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
Hi Martin,
I got around this issue simply by calling the following on each object =
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message=20
news:eqdq4q$v95$1@utils.eclipse.org...
Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode=20
is different for an empty and a 'filled' object. So to solve this I=20
would suggest that you change the hashcode method to be stable for both=20
cases and for different objects which are equal. The contract for the=20
hashcode() allows a fair amount of freedom for the implementation.=20
Afaics the equals method does not need to change for the=20
IdentifierCacheHandler (as it uses =3D=3D anyway).
The identifiercachehandler uses =3D=3D equals logic because it uses a=20
weakref and is really used to find the id for a loaded object from the=20
db.
Note that the identifiercachehandler is only used for so-called=20
synthetic id's which are created automatically when there is no id=20
attribute. Your issue should normally not arise if you have explicit id=20
attributes.
Overall I would also look at if you do not break any emf specifics as Ed =
pointed out.
gr. Martin
Ed Merks wrote:
Michael,
EObject implementations should not override equals or hashCode:=20
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D171299. Large portions=20
of the framework assume that there are no overrides and hence that =
=3D=3D=20
can be used in place of .equals. If I could, I would do as suggested=20
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
I've run into a problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties=20
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before=20
any of the properties are set. The Key inserted into the idMap has a=20
hashCode for an "empty" object. Once all the properties are set and=20
Hibernate is retrieving the identity to see if it has changed, the Key=20
used will not map to the original one since all the properties have=20
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of=20
SomeModelObjectClass was altered from 1 to null
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFl=
ushEntityEventListener.java:58)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(Default=
FlushEntityEventListener.java:157)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(Def=
aultFlushEntityEventListener.java:113)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(Abstr=
actFlushingEventListener.java:196)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToEx=
ecutions(AbstractFlushingEventListener.java:76)
at=20
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEve=
ntListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at=20
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106=
)
Is there any way to get around this issue without removing the=20
hashCode/equals implementations in my EObjects?
Thanks,
-mike
--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org=20
=20
=20
------=_NextPart_000_007D_01C75137.318A3220
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>These particular objects are never =
updated=20
after they are created the first time so the hashcode won't change. If =
they did=20
then you are certainly correct.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The reason had to bother with setting =
the=20
IdentifierCacheHandler at all is that these objects were retrieved as a =
part of=20
a transaction where other objects were getting updated. When the =
transaction was=20
committed the hibernate logic was checking to see if any of the objects =
were=20
dirty. Turns out that this calls Teneo's EntityPersister which indicated =
that=20
the identity of these objects was null since the hashCode =
changed. This=20
triggered Hibernate to think these objects were dirty and then threw an=20
exception saying that it doesn't know how to deal with null=20
identities.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for following up on this. I will =
certainly=20
recommend to people in my organization not to override EObject's =
hashcode/equals=20
methods.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-mike</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:er29fr$rf6$1@utils.eclipse.org">news:er29fr$rf6$1@utils.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>I=20
wonder if this implies that the map will be incomplete every time your =
object=20
changes state in a way that affects hashCode? <BR><BR><BR>Michael =
Kanaley=20
wrote:=20
<BLOCKQUOTE cite=3Dmider28jk$t73$1@utils.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for=20
myObject before any properties are set (it has the wrong hashCode). When =
my=20
application logic gets a hold of myObject (after all the properties of=20
myObject are set), I register another Key - the one that will actually =
be=20
used when commit is called. The Key registered by the Teneo library will =
just hang out in the map until myObject is GC'ed - it is never used by =
Teneo=20
or the application.
-mike
"Martin Taal" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:mtaal@elver.org"><mtaal@elver.org></A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:er1j1h$cs6$1@utils.eclipse.org">news:er1j1h$cs6$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Michael,
Thanks for the update, for my interest what is the summary object (is it =
equals to myObject)?
After it was loaded, you mean also before it was put in the=20
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Martin,
I got around this issue simply by calling the following on each object =
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:mtaal@elver.org"><mtaal@elver.org></A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:eqdq4q$v95$1@utils.eclipse.org">news:eqdq4q$v95$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode=20
is different for an empty and a 'filled' object. So to solve this I=20
would suggest that you change the hashcode method to be stable for both=20
cases and for different objects which are equal. The contract for the=20
hashcode() allows a fair amount of freedom for the implementation.=20
Afaics the equals method does not need to change for the=20
IdentifierCacheHandler (as it uses =3D=3D anyway).
The identifiercachehandler uses =3D=3D equals logic because it uses a=20
weakref and is really used to find the id for a loaded object from the=20
db.
Note that the identifiercachehandler is only used for so-called=20
synthetic id's which are created automatically when there is no id=20
attribute. Your issue should normally not arise if you have explicit id=20
attributes.
Overall I would also look at if you do not break any emf specifics as Ed =
pointed out.
gr. Martin
Ed Merks wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Michael,
EObject implementations should not override equals or hashCode:=20
<A class=3Dmoz-txt-link-freetext =
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D171299">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D171299</A>. Large portions=20
of the framework assume that there are no overrides and hence that =
=3D=3D=20
can be used in place of .equals. If I could, I would do as suggested=20
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">I've run into a =
problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties=20
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before=20
any of the properties are set. The Key inserted into the idMap has a=20
hashCode for an "empty" object. Once all the properties are set and=20
Hibernate is retrieving the identity to see if it has changed, the Key=20
used will not map to the original one since all the properties have=20
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of=20
SomeModelObjectClass was altered from 1 to null
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFl=
ushEntityEventListener.java:58)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(Default=
FlushEntityEventListener.java:157)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(Def=
aultFlushEntityEventListener.java:113)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(Abstr=
actFlushingEventListener.java:196)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToEx=
ecutions(AbstractFlushingEventListener.java:76)
at=20
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEve=
ntListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at=20
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106=
)
Is there any way to get around this issue without removing the=20
hashCode/equals implementations in my EObjects?
Thanks,
-mike
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@springsite.com">mtaal@springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@elver.org">mtaal@elver.org</A>
Web: <A class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.springsite.com">www.springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.elver.org">www.elver.org</A>
</PRE></BLOCKQUOTE><PRE wrap=3D""> </PRE></BLOCKQUOTE><PRE =
wrap=3D"">--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@springsite.com">mtaal@springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@elver.org">mtaal@elver.org</A>
Web: <A class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.springsite.com">www.springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.elver.org">www.elver.org</A>=20
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_007D_01C75137.318A3220--
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602301 is a reply to message #70749] |
Wed, 07 February 2007 19:00 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Michael,
EObject implementations should not override equals or hashCode:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions of
the framework assume that there are no overrides and hence that == can
be used in place of .equals. If I could, I would do as suggested in
the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
> I've run into a problem with Teneo.
> Some of my EObjects implement hashCode/equals using the properties stored in
> the EObject.
> It appears that Teneo updates the IdentifierCacheHandler.idMap before any of
> the properties are set. The Key inserted into the idMap has a hashCode for
> an "empty" object. Once all the properties are set and Hibernate is
> retrieving the identity to see if it has changed, the Key used will not map
> to the original one since all the properties have been set. This leads to an
> exception similar to the following:
> org.hibernate.HibernateException: identifier of an instance of
> SomeModelObjectClass was altered from 1 to null
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
> at
> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
> at
> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>
> Is there any way to get around this issue without removing the
> hashCode/equals implementations in my EObjects?
> Thanks,
> -mike
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602361 is a reply to message #70834] |
Thu, 08 February 2007 12:16 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Martin,
So that's a good reason why making them final might be upsetting to
folks, but doing not following the EMF advice in an EMF context is
likely to break assumptions in EMF. Not only is writing a good
implementation of hashCode and equals far trickier than it should be but
having the hashCode depend on the state of the object makes it very
dangerous to ever make an EObject be the key of a map, since Java's map
implementations assume that the hashCode of a key does not change, and
if it does, the map is corrupted. There is no checking for this, so
it's likely to lead to horrible bugs. You could never, for example,
rely on using a WeakHashMap to associate data with mutable EObjects
(unless you derived your own from something like IdentityHashMap). So
in EMF, overriding equals and hashCode for EObjects is done at your own
risk...
Martin Taal wrote:
> Hi Ed,
> The override argument can also come from Hibernate: the hibernate
> manual explicitly states that for specific cases you should override
> hashcode and equals and let these methods use meaningfull information
> from the objects itself. So there are two frameworks with opposing
> guidelines.
>
> gr. Martin
>
> Ed Merks wrote:
>> Michael,
>>
>> EObject implementations should not override equals or hashCode:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions
>> of the framework assume that there are no overrides and hence that ==
>> can be used in place of .equals. If I could, I would do as
>> suggested in the bug and make these methods final in BasicEObjectImpl.
>>
>>
>> Michael Kanaley wrote:
>>> I've run into a problem with Teneo.
>>> Some of my EObjects implement hashCode/equals using the properties
>>> stored in the EObject.
>>> It appears that Teneo updates the IdentifierCacheHandler.idMap
>>> before any of the properties are set. The Key inserted into the
>>> idMap has a hashCode for an "empty" object. Once all the properties
>>> are set and Hibernate is retrieving the identity to see if it has
>>> changed, the Key used will not map to the original one since all the
>>> properties have been set. This leads to an exception similar to the
>>> following:
>>> org.hibernate.HibernateException: identifier of an instance of
>>> SomeModelObjectClass was altered from 1 to null
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>> at
>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>
>>>
>>> Is there any way to get around this issue without removing the
>>> hashCode/equals implementations in my EObjects?
>>> Thanks,
>>> -mike
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602584 is a reply to message #70854] |
Thu, 15 February 2007 10:15 |
Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
Hi Martin,
I got around this issue simply by calling the following on each object
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message
news:eqdq4q$v95$1@utils.eclipse.org...
> Michael,
> Your issue with the IdentifierCacheHandler arises because the hashcode is
> different for an empty and a 'filled' object. So to solve this I would
> suggest that you change the hashcode method to be stable for both cases
> and for different objects which are equal. The contract for the hashcode()
> allows a fair amount of freedom for the implementation. Afaics the equals
> method does not need to change for the IdentifierCacheHandler (as it uses
> == anyway).
>
> The identifiercachehandler uses == equals logic because it uses a weakref
> and is really used to find the id for a loaded object from the db.
>
> Note that the identifiercachehandler is only used for so-called synthetic
> id's which are created automatically when there is no id attribute. Your
> issue should normally not arise if you have explicit id attributes.
>
> Overall I would also look at if you do not break any emf specifics as Ed
> pointed out.
>
> gr. Martin
>
> Ed Merks wrote:
>> Michael,
>>
>> EObject implementations should not override equals or hashCode:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions of
>> the framework assume that there are no overrides and hence that == can be
>> used in place of .equals. If I could, I would do as suggested in the
>> bug and make these methods final in BasicEObjectImpl.
>>
>>
>> Michael Kanaley wrote:
>>> I've run into a problem with Teneo.
>>> Some of my EObjects implement hashCode/equals using the properties
>>> stored in the EObject.
>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>> any of the properties are set. The Key inserted into the idMap has a
>>> hashCode for an "empty" object. Once all the properties are set and
>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>> used will not map to the original one since all the properties have been
>>> set. This leads to an exception similar to the following:
>>> org.hibernate.HibernateException: identifier of an instance of
>>> SomeModelObjectClass was altered from 1 to null
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>> at
>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>
>>> Is there any way to get around this issue without removing the
>>> hashCode/equals implementations in my EObjects?
>>> Thanks,
>>> -mike
>>>
>>>
>
>
> --
>
> With Regards, Martin Taal
>
> Springsite/Elver.org
> Office: Hardwareweg 4, 3821 BV Amersfoort
> Postal: Nassaulaan 7, 3941 EC Doorn
> The Netherlands
> Tel: +31 (0)84 420 2397
> Fax: +31 (0)84 225 9307
> Mail: mtaal@springsite.com - mtaal@elver.org
> Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602608 is a reply to message #71695] |
Thu, 15 February 2007 12:17 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Michael,
Thanks for the update, for my interest what is the summary object (is it equals to myObject)?
After it was loaded, you mean also before it was put in the IdentifierCacheHandler (with a wrong
hascode?)?
gr. Martin
Michael Kanaley wrote:
> Hi Martin,
> I got around this issue simply by calling the following on each object
> after it was loaded:
> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>
> The Hibernate Session holds the id value.
>
> -mike
>
> "Martin Taal" <mtaal@elver.org> wrote in message
> news:eqdq4q$v95$1@utils.eclipse.org...
>> Michael,
>> Your issue with the IdentifierCacheHandler arises because the hashcode is
>> different for an empty and a 'filled' object. So to solve this I would
>> suggest that you change the hashcode method to be stable for both cases
>> and for different objects which are equal. The contract for the hashcode()
>> allows a fair amount of freedom for the implementation. Afaics the equals
>> method does not need to change for the IdentifierCacheHandler (as it uses
>> == anyway).
>>
>> The identifiercachehandler uses == equals logic because it uses a weakref
>> and is really used to find the id for a loaded object from the db.
>>
>> Note that the identifiercachehandler is only used for so-called synthetic
>> id's which are created automatically when there is no id attribute. Your
>> issue should normally not arise if you have explicit id attributes.
>>
>> Overall I would also look at if you do not break any emf specifics as Ed
>> pointed out.
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Michael,
>>>
>>> EObject implementations should not override equals or hashCode:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions of
>>> the framework assume that there are no overrides and hence that == can be
>>> used in place of .equals. If I could, I would do as suggested in the
>>> bug and make these methods final in BasicEObjectImpl.
>>>
>>>
>>> Michael Kanaley wrote:
>>>> I've run into a problem with Teneo.
>>>> Some of my EObjects implement hashCode/equals using the properties
>>>> stored in the EObject.
>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>> any of the properties are set. The Key inserted into the idMap has a
>>>> hashCode for an "empty" object. Once all the properties are set and
>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>> used will not map to the original one since all the properties have been
>>>> set. This leads to an exception similar to the following:
>>>> org.hibernate.HibernateException: identifier of an instance of
>>>> SomeModelObjectClass was altered from 1 to null
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>> at
>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>
>>>> Is there any way to get around this issue without removing the
>>>> hashCode/equals implementations in my EObjects?
>>>> Thanks,
>>>> -mike
>>>>
>>>>
>>
>> --
>>
>> With Regards, Martin Taal
>>
>> Springsite/Elver.org
>> Office: Hardwareweg 4, 3821 BV Amersfoort
>> Postal: Nassaulaan 7, 3941 EC Doorn
>> The Netherlands
>> Tel: +31 (0)84 420 2397
>> Fax: +31 (0)84 225 9307
>> Mail: mtaal@springsite.com - mtaal@elver.org
>> Web: www.springsite.com - www.elver.org
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602628 is a reply to message #71752] |
Thu, 15 February 2007 18:25 |
Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for
myObject before any properties are set (it has the wrong hashCode). When my
application logic gets a hold of myObject (after all the properties of
myObject are set), I register another Key - the one that will actually be
used when commit is called. The Key registered by the Teneo library will
just hang out in the map until myObject is GC'ed - it is never used by Teneo
or the application.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message
news:er1j1h$cs6$1@utils.eclipse.org...
> Hi Michael,
> Thanks for the update, for my interest what is the summary object (is it
> equals to myObject)?
> After it was loaded, you mean also before it was put in the
> IdentifierCacheHandler (with a wrong hascode?)?
>
> gr. Martin
>
> Michael Kanaley wrote:
>> Hi Martin,
>> I got around this issue simply by calling the following on each object
>> after it was loaded:
>> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>>
>> The Hibernate Session holds the id value.
>>
>> -mike
>>
>> "Martin Taal" <mtaal@elver.org> wrote in message
>> news:eqdq4q$v95$1@utils.eclipse.org...
>>> Michael,
>>> Your issue with the IdentifierCacheHandler arises because the hashcode
>>> is different for an empty and a 'filled' object. So to solve this I
>>> would suggest that you change the hashcode method to be stable for both
>>> cases and for different objects which are equal. The contract for the
>>> hashcode() allows a fair amount of freedom for the implementation.
>>> Afaics the equals method does not need to change for the
>>> IdentifierCacheHandler (as it uses == anyway).
>>>
>>> The identifiercachehandler uses == equals logic because it uses a
>>> weakref and is really used to find the id for a loaded object from the
>>> db.
>>>
>>> Note that the identifiercachehandler is only used for so-called
>>> synthetic id's which are created automatically when there is no id
>>> attribute. Your issue should normally not arise if you have explicit id
>>> attributes.
>>>
>>> Overall I would also look at if you do not break any emf specifics as Ed
>>> pointed out.
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>> Michael,
>>>>
>>>> EObject implementations should not override equals or hashCode:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions
>>>> of the framework assume that there are no overrides and hence that ==
>>>> can be used in place of .equals. If I could, I would do as suggested
>>>> in the bug and make these methods final in BasicEObjectImpl.
>>>>
>>>>
>>>> Michael Kanaley wrote:
>>>>> I've run into a problem with Teneo.
>>>>> Some of my EObjects implement hashCode/equals using the properties
>>>>> stored in the EObject.
>>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>>> any of the properties are set. The Key inserted into the idMap has a
>>>>> hashCode for an "empty" object. Once all the properties are set and
>>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>>> used will not map to the original one since all the properties have
>>>>> been set. This leads to an exception similar to the following:
>>>>> org.hibernate.HibernateException: identifier of an instance of
>>>>> SomeModelObjectClass was altered from 1 to null
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>>> at
>>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>>
>>>>> Is there any way to get around this issue without removing the
>>>>> hashCode/equals implementations in my EObjects?
>>>>> Thanks,
>>>>> -mike
>>>>>
>>>>>
>>>
>>> --
>>>
>>> With Regards, Martin Taal
>>>
>>> Springsite/Elver.org
>>> Office: Hardwareweg 4, 3821 BV Amersfoort
>>> Postal: Nassaulaan 7, 3941 EC Doorn
>>> The Netherlands
>>> Tel: +31 (0)84 420 2397
>>> Fax: +31 (0)84 225 9307
>>> Mail: mtaal@springsite.com - mtaal@elver.org
>>> Web: www.springsite.com - www.elver.org
>>
>>
>
>
> --
>
> With Regards, Martin Taal
>
> Springsite/Elver.org
> Office: Hardwareweg 4, 3821 BV Amersfoort
> Postal: Nassaulaan 7, 3941 EC Doorn
> The Netherlands
> Tel: +31 (0)84 420 2397
> Fax: +31 (0)84 225 9307
> Mail: mtaal@springsite.com - mtaal@elver.org
> Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602638 is a reply to message #71827] |
Thu, 15 February 2007 18:40 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010204020003090807000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Michael,
I wonder if this implies that the map will be incomplete every time your
object changes state in a way that affects hashCode?
Michael Kanaley wrote:
> Sorry,
> that should have read:
> IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
>
> The Teneo library is updating the IdentifierCacheHandler with a Key for
> myObject before any properties are set (it has the wrong hashCode). When my
> application logic gets a hold of myObject (after all the properties of
> myObject are set), I register another Key - the one that will actually be
> used when commit is called. The Key registered by the Teneo library will
> just hang out in the map until myObject is GC'ed - it is never used by Teneo
> or the application.
> -mike
>
> "Martin Taal" <mtaal@elver.org> wrote in message
> news:er1j1h$cs6$1@utils.eclipse.org...
>
>> Hi Michael,
>> Thanks for the update, for my interest what is the summary object (is it
>> equals to myObject)?
>> After it was loaded, you mean also before it was put in the
>> IdentifierCacheHandler (with a wrong hascode?)?
>>
>> gr. Martin
>>
>> Michael Kanaley wrote:
>>
>>> Hi Martin,
>>> I got around this issue simply by calling the following on each object
>>> after it was loaded:
>>> IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
>>>
>>> The Hibernate Session holds the id value.
>>>
>>> -mike
>>>
>>> "Martin Taal" <mtaal@elver.org> wrote in message
>>> news:eqdq4q$v95$1@utils.eclipse.org...
>>>
>>>> Michael,
>>>> Your issue with the IdentifierCacheHandler arises because the hashcode
>>>> is different for an empty and a 'filled' object. So to solve this I
>>>> would suggest that you change the hashcode method to be stable for both
>>>> cases and for different objects which are equal. The contract for the
>>>> hashcode() allows a fair amount of freedom for the implementation.
>>>> Afaics the equals method does not need to change for the
>>>> IdentifierCacheHandler (as it uses == anyway).
>>>>
>>>> The identifiercachehandler uses == equals logic because it uses a
>>>> weakref and is really used to find the id for a loaded object from the
>>>> db.
>>>>
>>>> Note that the identifiercachehandler is only used for so-called
>>>> synthetic id's which are created automatically when there is no id
>>>> attribute. Your issue should normally not arise if you have explicit id
>>>> attributes.
>>>>
>>>> Overall I would also look at if you do not break any emf specifics as Ed
>>>> pointed out.
>>>>
>>>> gr. Martin
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> EObject implementations should not override equals or hashCode:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299 Large portions
>>>>> of the framework assume that there are no overrides and hence that ==
>>>>> can be used in place of .equals. If I could, I would do as suggested
>>>>> in the bug and make these methods final in BasicEObjectImpl.
>>>>>
>>>>>
>>>>> Michael Kanaley wrote:
>>>>>
>>>>>> I've run into a problem with Teneo.
>>>>>> Some of my EObjects implement hashCode/equals using the properties
>>>>>> stored in the EObject.
>>>>>> It appears that Teneo updates the IdentifierCacheHandler.idMap before
>>>>>> any of the properties are set. The Key inserted into the idMap has a
>>>>>> hashCode for an "empty" object. Once all the properties are set and
>>>>>> Hibernate is retrieving the identity to see if it has changed, the Key
>>>>>> used will not map to the original one since all the properties have
>>>>>> been set. This leads to an exception similar to the following:
>>>>>> org.hibernate.HibernateException: identifier of an instance of
>>>>>> SomeModelObjectClass was altered from 1 to null
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>>>>> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
>>>>>> at
>>>>>> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
>>>>>>
>>>>>> Is there any way to get around this issue without removing the
>>>>>> hashCode/equals implementations in my EObjects?
>>>>>> Thanks,
>>>>>> -mike
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>>
>>>> With Regards, Martin Taal
>>>>
>>>> Springsite/Elver.org
>>>> Office: Hardwareweg 4, 3821 BV Amersfoort
>>>> Postal: Nassaulaan 7, 3941 EC Doorn
>>>> The Netherlands
>>>> Tel: +31 (0)84 420 2397
>>>> Fax: +31 (0)84 225 9307
>>>> Mail: mtaal@springsite.com - mtaal@elver.org
>>>> Web: www.springsite.com - www.elver.org
>>>>
>>>
>> --
>>
>> With Regards, Martin Taal
>>
>> Springsite/Elver.org
>> Office: Hardwareweg 4, 3821 BV Amersfoort
>> Postal: Nassaulaan 7, 3941 EC Doorn
>> The Netherlands
>> Tel: +31 (0)84 420 2397
>> Fax: +31 (0)84 225 9307
>> Mail: mtaal@springsite.com - mtaal@elver.org
>> Web: www.springsite.com - www.elver.org
>>
>
>
>
--------------010204020003090807000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
I wonder if this implies that the map will be incomplete every time
your object changes state in a way that affects hashCode? <br>
<br>
<br>
Michael Kanaley wrote:
<blockquote cite="mider28jk$t73$1@utils.eclipse.org" type="cite">
<pre wrap="">Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for
myObject before any properties are set (it has the wrong hashCode). When my
application logic gets a hold of myObject (after all the properties of
myObject are set), I register another Key - the one that will actually be
used when commit is called. The Key registered by the Teneo library will
just hang out in the map until myObject is GC'ed - it is never used by Teneo
or the application.
-mike
"Martin Taal" <a class="moz-txt-link-rfc2396E" href="mailto:mtaal@elver.org"><mtaal@elver.org></a> wrote in message
<a class="moz-txt-link-freetext" href="news:er1j1h$cs6$1@utils.eclipse.org">news:er1j1h$cs6$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Michael,
Thanks for the update, for my interest what is the summary object (is it
equals to myObject)?
After it was loaded, you mean also before it was put in the
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Martin,
I got around this issue simply by calling the following on each object
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <a class="moz-txt-link-rfc2396E" href="mailto:mtaal@elver.org"><mtaal@elver.org></a> wrote in message
<a class="moz-txt-link-freetext" href="news:eqdq4q$v95$1@utils.eclipse.org">news:eqdq4q$v95$1@utils.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode
is different for an empty and a 'filled' object. So to solve this I
would suggest that you change the hashcode method to be stable for both
cases and for different objects which are equal. The contract for the
hashcode() allows a fair amount of freedom for the implementation.
Afaics the equals method does not need to change for the
IdentifierCacheHandler (as it uses == anyway).
The identifiercachehandler uses == equals logic because it uses a
weakref and is really used to find the id for a loaded object from the
db.
Note that the identifiercachehandler is only used for so-called
synthetic id's which are created automatically when there is no id
attribute. Your issue should normally not arise if you have explicit id
attributes.
Overall I would also look at if you do not break any emf specifics as Ed
pointed out.
gr. Martin
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Michael,
EObject implementations should not override equals or hashCode:
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299">https://bugs.eclipse.org/bugs/show_bug.cgi?id=171299</a>. Large portions
of the framework assume that there are no overrides and hence that ==
can be used in place of .equals. If I could, I would do as suggested
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've run into a problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before
any of the properties are set. The Key inserted into the idMap has a
hashCode for an "empty" object. Once all the properties are set and
Hibernate is retrieving the identity to see if it has changed, the Key
used will not map to the original one since all the properties have
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of
SomeModelObjectClass was altered from 1 to null
at
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFlushEntityEventListener.java:58)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(DefaultFlushEntityEventListener.java:157)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:113)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106)
Is there any way to get around this issue without removing the
hashCode/equals implementations in my EObjects?
Thanks,
-mike
</pre>
</blockquote>
</blockquote>
<pre wrap="">--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <a class="moz-txt-link-abbreviated" href="mailto:mtaal@springsite.com">mtaal@springsite.com</a> - <a class="moz-txt-link-abbreviated" href="mailto:mtaal@elver.org">mtaal@elver.org</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.springsite.com">www.springsite.com</a> - <a class="moz-txt-link-abbreviated" href="http://www.elver.org">www.elver.org</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <a class="moz-txt-link-abbreviated" href="mailto:mtaal@springsite.com">mtaal@springsite.com</a> - <a class="moz-txt-link-abbreviated" href="mailto:mtaal@elver.org">mtaal@elver.org</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.springsite.com">www.springsite.com</a> - <a class="moz-txt-link-abbreviated" href="http://www.elver.org">www.elver.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------010204020003090807000403--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #602658 is a reply to message #71847] |
Thu, 15 February 2007 22:26 |
Michael Kanaley
Messages: 89
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_007D_01C75137.318A3220
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
These particular objects are never updated after they are created the =
first time so the hashcode won't change. If they did then you are =
certainly correct.
The reason had to bother with setting the IdentifierCacheHandler at all =
is that these objects were retrieved as a part of a transaction where =
other objects were getting updated. When the transaction was committed =
the hibernate logic was checking to see if any of the objects were =
dirty. Turns out that this calls Teneo's EntityPersister which indicated =
that the identity of these objects was null since the hashCode changed. =
This triggered Hibernate to think these objects were dirty and then =
threw an exception saying that it doesn't know how to deal with null =
identities.
Thanks for following up on this. I will certainly recommend to people in =
my organization not to override EObject's hashcode/equals methods.
-mike
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:er29fr$rf6$1@utils.eclipse.org...
Michael,
I wonder if this implies that the map will be incomplete every time =
your object changes state in a way that affects hashCode?=20
Michael Kanaley wrote:=20
Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for=20
myObject before any properties are set (it has the wrong hashCode). When =
my=20
application logic gets a hold of myObject (after all the properties of=20
myObject are set), I register another Key - the one that will actually =
be=20
used when commit is called. The Key registered by the Teneo library will =
just hang out in the map until myObject is GC'ed - it is never used by =
Teneo=20
or the application.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message=20
news:er1j1h$cs6$1@utils.eclipse.org...
Hi Michael,
Thanks for the update, for my interest what is the summary object (is it =
equals to myObject)?
After it was loaded, you mean also before it was put in the=20
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
Hi Martin,
I got around this issue simply by calling the following on each object =
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <mtaal@elver.org> wrote in message=20
news:eqdq4q$v95$1@utils.eclipse.org...
Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode=20
is different for an empty and a 'filled' object. So to solve this I=20
would suggest that you change the hashcode method to be stable for both=20
cases and for different objects which are equal. The contract for the=20
hashcode() allows a fair amount of freedom for the implementation.=20
Afaics the equals method does not need to change for the=20
IdentifierCacheHandler (as it uses =3D=3D anyway).
The identifiercachehandler uses =3D=3D equals logic because it uses a=20
weakref and is really used to find the id for a loaded object from the=20
db.
Note that the identifiercachehandler is only used for so-called=20
synthetic id's which are created automatically when there is no id=20
attribute. Your issue should normally not arise if you have explicit id=20
attributes.
Overall I would also look at if you do not break any emf specifics as Ed =
pointed out.
gr. Martin
Ed Merks wrote:
Michael,
EObject implementations should not override equals or hashCode:=20
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D171299 Large portions=20
of the framework assume that there are no overrides and hence that =
=3D=3D=20
can be used in place of .equals. If I could, I would do as suggested=20
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
I've run into a problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties=20
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before=20
any of the properties are set. The Key inserted into the idMap has a=20
hashCode for an "empty" object. Once all the properties are set and=20
Hibernate is retrieving the identity to see if it has changed, the Key=20
used will not map to the original one since all the properties have=20
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of=20
SomeModelObjectClass was altered from 1 to null
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFl=
ushEntityEventListener.java:58)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(Default=
FlushEntityEventListener.java:157)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(Def=
aultFlushEntityEventListener.java:113)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(Abstr=
actFlushingEventListener.java:196)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToEx=
ecutions(AbstractFlushingEventListener.java:76)
at=20
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEve=
ntListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at=20
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106=
)
Is there any way to get around this issue without removing the=20
hashCode/equals implementations in my EObjects?
Thanks,
-mike
--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org=20
=20
=20
------=_NextPart_000_007D_01C75137.318A3220
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>These particular objects are never =
updated=20
after they are created the first time so the hashcode won't change. If =
they did=20
then you are certainly correct.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The reason had to bother with setting =
the=20
IdentifierCacheHandler at all is that these objects were retrieved as a =
part of=20
a transaction where other objects were getting updated. When the =
transaction was=20
committed the hibernate logic was checking to see if any of the objects =
were=20
dirty. Turns out that this calls Teneo's EntityPersister which indicated =
that=20
the identity of these objects was null since the hashCode =
changed. This=20
triggered Hibernate to think these objects were dirty and then threw an=20
exception saying that it doesn't know how to deal with null=20
identities.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for following up on this. I will =
certainly=20
recommend to people in my organization not to override EObject's =
hashcode/equals=20
methods.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-mike</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:er29fr$rf6$1@utils.eclipse.org">news:er29fr$rf6$1@utils.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>I=20
wonder if this implies that the map will be incomplete every time your =
object=20
changes state in a way that affects hashCode? <BR><BR><BR>Michael =
Kanaley=20
wrote:=20
<BLOCKQUOTE cite=3Dmider28jk$t73$1@utils.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Sorry,
that should have read:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(myObject));
The Teneo library is updating the IdentifierCacheHandler with a Key for=20
myObject before any properties are set (it has the wrong hashCode). When =
my=20
application logic gets a hold of myObject (after all the properties of=20
myObject are set), I register another Key - the one that will actually =
be=20
used when commit is called. The Key registered by the Teneo library will =
just hang out in the map until myObject is GC'ed - it is never used by =
Teneo=20
or the application.
-mike
"Martin Taal" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:mtaal@elver.org"><mtaal@elver.org></A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:er1j1h$cs6$1@utils.eclipse.org">news:er1j1h$cs6$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Michael,
Thanks for the update, for my interest what is the summary object (is it =
equals to myObject)?
After it was loaded, you mean also before it was put in the=20
IdentifierCacheHandler (with a wrong hascode?)?
gr. Martin
Michael Kanaley wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Martin,
I got around this issue simply by calling the following on each object =
after it was loaded:
IdentifierCacheHandler.setID(myObject, session.getIdentifier(summary));
The Hibernate Session holds the id value.
-mike
"Martin Taal" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:mtaal@elver.org"><mtaal@elver.org></A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:eqdq4q$v95$1@utils.eclipse.org">news:eqdq4q$v95$1@utils.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Michael,
Your issue with the IdentifierCacheHandler arises because the hashcode=20
is different for an empty and a 'filled' object. So to solve this I=20
would suggest that you change the hashcode method to be stable for both=20
cases and for different objects which are equal. The contract for the=20
hashcode() allows a fair amount of freedom for the implementation.=20
Afaics the equals method does not need to change for the=20
IdentifierCacheHandler (as it uses =3D=3D anyway).
The identifiercachehandler uses =3D=3D equals logic because it uses a=20
weakref and is really used to find the id for a loaded object from the=20
db.
Note that the identifiercachehandler is only used for so-called=20
synthetic id's which are created automatically when there is no id=20
attribute. Your issue should normally not arise if you have explicit id=20
attributes.
Overall I would also look at if you do not break any emf specifics as Ed =
pointed out.
gr. Martin
Ed Merks wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Michael,
EObject implementations should not override equals or hashCode:=20
<A class=3Dmoz-txt-link-freetext =
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D171299">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D171299</A>. Large portions=20
of the framework assume that there are no overrides and hence that =
=3D=3D=20
can be used in place of .equals. If I could, I would do as suggested=20
in the bug and make these methods final in BasicEObjectImpl.
Michael Kanaley wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">I've run into a =
problem with Teneo.
Some of my EObjects implement hashCode/equals using the properties=20
stored in the EObject.
It appears that Teneo updates the IdentifierCacheHandler.idMap before=20
any of the properties are set. The Key inserted into the idMap has a=20
hashCode for an "empty" object. Once all the properties are set and=20
Hibernate is retrieving the identity to see if it has changed, the Key=20
used will not map to the original one since all the properties have=20
been set. This leads to an exception similar to the following:
org.hibernate.HibernateException: identifier of an instance of=20
SomeModelObjectClass was altered from 1 to null
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.chec kId(DefaultFl=
ushEntityEventListener.java:58)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.getV alues(Default=
FlushEntityEventListener.java:157)
at=20
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(Def=
aultFlushEntityEventListener.java:113)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(Abstr=
actFlushingEventListener.java:196)
at=20
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToEx=
ecutions(AbstractFlushingEventListener.java:76)
at=20
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEve=
ntListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java :338)
at=20
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransac tion.java:106=
)
Is there any way to get around this issue without removing the=20
hashCode/equals implementations in my EObjects?
Thanks,
-mike
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@springsite.com">mtaal@springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@elver.org">mtaal@elver.org</A>
Web: <A class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.springsite.com">www.springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.elver.org">www.elver.org</A>
</PRE></BLOCKQUOTE><PRE wrap=3D""> </PRE></BLOCKQUOTE><PRE =
wrap=3D"">--=20
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@springsite.com">mtaal@springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:mtaal@elver.org">mtaal@elver.org</A>
Web: <A class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.springsite.com">www.springsite.com</A> - <A =
class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.elver.org">www.elver.org</A>=20
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_007D_01C75137.318A3220--
|
|
|
Goto Forum:
Current Time: Thu Apr 18 23:54:52 GMT 2024
Powered by FUDForum. Page generated in 0.03141 seconds |
] 
Search
Help
Register
Login
Home
