Re: [eclipselink-users] object/entity identity in EclipseLink (JPA)

["Thomas Paradies" <paradies@xxxxxxxxxxxxxxxxx>]

James,

thank you for your explanation and sorry for confusion due to my
injudiciousness - it is so apparently ...

Thomas

> I think you are being confused by the logging.
>
> In EclipseLink there is a "shared" object cache, and a
> "transactional/entity-manager" cache.  When you read an object, the object
> is either found in the shared cache, or read from the database and put in
> the shared cache (at least in the normal case).  This shared object is
> then
> registered into the transactional/entity-manager context/cache.  The log
> you
> are seeing is for the shared object being registered into the
> transactional
> context, then object you get back is the transactional copy.
>
> When you change your hashcode, you are just changing the toString of your
> object, it is still a different object being registered.
>
> In general in JPA when you read the same object from the same
> EntityManager
> you will get back the identical object (==).  If you read the same object
> from different EntityManagers you will get back different objects (!=).
> If
> you are using a JTA managed EntityManager, you will get back a different
> object in each transaction.
>
>
>
> Thomas Paradies wrote:
>>
>> Shaun,
>>
>> sorry for late reply, a disease inhibited me.
>>
>> My comments inlined below:
>>
>>> Hi Thomas,
>>>
>>>    EclipseLink does not make use of hashCode() and equals() in it's
>>> cache management.  We use an object's identity.  It's not clear from
>>> the
>>> log what your code is doing.  Can you show your code and the log
>>> messages inlined?
>>
>> I think the code is not helpful here, it is as simple as I wrote: It
>> fetches an entity object of type Division which has an @Id field by the
>> value of this id field. (BTW, does object's identity mean entity
>> identity?)
>>
>> For me the relevant log messages are the following:
>> ...
>> [EPS Finer]: ServerSession(13359904)--client acquired
>> [EPS Finest]: UnitOfWork(12342678)--Execute query ReadAllQuery(Division)
>> [EPS Fine]: ServerSession(13359904)--Connection(3807284)--SELECT
>> DIVISION_ID FROM DIVISIONS WHERE (DIVISION_ID = ?)
>> 	bind => [101]
>> [EPS Finest]: UnitOfWork(12342678)--Register the existing object
>> Division@12e7c6a
>> -> fetchDivision(101) returns: Division@970c0e
>> ...
>>
>> How I read this messages: In the Unit of Work is an Division object
>> (Division@12e7c6a) registered. My fetch method returns another Division
>> object (Division@970c0e). So I have two objects with the same identity,
>> right? And here I thought pracmatically they have to be the same.
>>
>> Because this was not the expected result in a second step I implemented
>> hashCode() and equals() for my Division class to see what's happening
>> than.
>>
>> The log shows than:
>> ...
>> [EPS Finer]: ServerSession(13359904)--client acquired
>> [EPS Finest]: UnitOfWork(12342678)--Execute query ReadAllQuery(Division)
>> [EPS Fine]: ServerSession(13359904)--Connection(3807284)--SELECT
>> DIVISION_ID FROM DIVISIONS WHERE (DIVISION_ID = ?)
>> 	bind => [101]
>> [EPS Finest]: UnitOfWork(12342678)--Register the existing object
>> Division@12e7c6a
>> -> fetchDivision(101) returns: Division@12e7c6a
>> ...
>>
>> Obviously my method now returns the object which was before registered
>> by/in the Unit of Work. Strange, or?
>>
>> If you only use an object's identity, why shows EclipseLink this
>> behaviour? Or, how I have to read the log in these cases?
>>
>> Thomas
>>
>>>
>>>    Repeated queries for the same object on the same EntityManager will
>>> give you back the exact same instance.  Each will be == the other.  If
>>> you query against different EntityManagers you will get different
>>> instances that are not from the same persistence context and are not
>>> ==.
>>>
>>>     Shaun
>>>
>>> Thomas Paradies wrote:
>>>> Hi there,
>>>>
>>>> I need some help to understand the following two eclipselink log
>>>> snippets,
>>>> which I got with a simple jpa test case - fetching a single object
>>>> from
>>>> db
>>>> with default configuration settings (cache...). Division is an jpa
>>>> entity
>>>> with an unique identity 101.
>>>>
>>>> In each log snippet the first line is eclipselink output and the
>>>> second
>>>> line shows the hashCode of the returned object.
>>>>
>>>> TC1 Division hasn't implementations for hashCode() and equals() - it
>>>> seems, we have two objects with the same entity identity but different
>>>> hashCodes.
>>>> ###
>>>> [EPS Finest]: UnitOfWork(23582715)--Register the existing object
>>>> Division@12e7c6a
>>>> -> fetchDivision(101) returns: Division@49cf9f
>>>> ###
>>>>
>>>>
>>>> TC2 Division has implementations for hashCode() and equals() - now we
>>>> have
>>>> one object.
>>>> ###
>>>> [EPS Finest]: UnitOfWork(23582715)--Register the existing object
>>>> Division@38766d79
>>>> -> fetchDivision(101) returns: Division@38766d79
>>>> ###
>>>>
>>>> Can somebody explain this effect? Should I always implement hashCode()
>>>> and
>>>> equals() to be sure I have only one object per entity (id)? Or is the
>>>> fist
>>>> case right? Isn't that a problem e.g. for caching?
>>>>
>>>> Thomas
>>
>
>
> -----
> ---
> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
> http://www.eclipse.org/eclipselink/
>  EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
> TopLink
> Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
> http://wiki.oracle.com/page/TopLink TopLink
> Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
> http://www.nabble.com/EclipseLink-f26430.html EclipseLink
> Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
> --
> View this message in context:
> http://www.nabble.com/object-entity-identity-in-EclipseLink-%28JPA%29-tp17426077p17648975.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>