Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations
[Teneo] IdentifierCacheHandler does not work for EObjects with hashCode implementations [message #70749] Wed, 07 February 2007 18:32 Go to next message
Michael Kanaley is currently offline Michael KanaleyFriend
Messages: 89
Registered: July 2009
Member
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 #70754 is a reply to message #70749] Wed, 07 February 2007 19:00 Go to previous messageGo to next message
Eclipse UserFriend
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 #70834 is a reply to message #70754] Thu, 08 February 2007 00:10 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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
>>
>>


--

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 #70854 is a reply to message #70754] Thu, 08 February 2007 00:16 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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 #71013 is a reply to message #70834] Thu, 08 February 2007 12:16 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Michael Kanaley is currently offline Michael KanaleyFriend
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 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous messageGo to next message
Michael Kanaley is currently offline Michael KanaleyFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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">&lt;mtaal@elver.org&gt;</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">&lt;mtaal@elver.org&gt;</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 Go to previous message
Michael Kanaley is currently offline Michael KanaleyFriend
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&nbsp;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>&nbsp;</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.&nbsp;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>&nbsp;</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" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=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">&lt;mtaal@elver.org&gt;</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">&lt;mtaal@elver.org&gt;</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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31543
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 #602319 is a reply to message #70754] Thu, 08 February 2007 00:10 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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
>>
>>


--

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 #602325 is a reply to message #70754] Thu, 08 February 2007 00:16 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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 #602361 is a reply to message #70834] Thu, 08 February 2007 12:16 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31543
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 Go to previous message
Michael Kanaley is currently offline Michael KanaleyFriend
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 Go to previous message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous message
Michael Kanaley is currently offline Michael KanaleyFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31543
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">&lt;mtaal@elver.org&gt;</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">&lt;mtaal@elver.org&gt;</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 Go to previous message
Michael Kanaley is currently offline Michael KanaleyFriend
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&nbsp;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>&nbsp;</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.&nbsp;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>&nbsp;</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" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=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">&lt;mtaal@elver.org&gt;</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">&lt;mtaal@elver.org&gt;</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--
Previous Topic:[Teneo] Seems that EAttributes of type EByteArray are not mapped correctly against hibernate
Next Topic:Why is the unique attribute of EAttribute ignored?
Goto Forum:
  


Current Time: Sat Oct 24 00:34:53 GMT 2020

Powered by FUDForum. Page generated in 0.03948 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top