Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] object/entity identity in EclipseLink (JPA) 
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.

Back to the top