• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate question: persistent identity

 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Everyone:

From the Hibernate documentation:



persistent

The instance is currently associated with a persistence context. It has a persistent identity (primary key value) and, perhaps, a corresponding row in the database. For a particular persistence context, Hibernate guarantees that persistent identity is equivalent to Java identity (in-memory location of the object).



What does it mean? They say that when when the instance is "persistent", the value of its primary key field (== "persistent identity") equals the address of that object (the in-memory location of the object).

How can is be??? What the primary key of the instance is int and equals 2, but the object is located at address CAFEBABE0x ??? How can they say that 2==CAFEBABE0x ???
[ November 13, 2007: Message edited by: Joseph Sweet ]
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Joseph, yes I can see how we can easily interpret that as saying that the PK is the exact memory address.

But, what it really says is that it needs to guarantee that java identity "==" will return true if and only if pk of the object .equals() the pk of the record in the database. This is why you need to use a PK that is truely Unique, and in cases where you are going to use detached objects, that you implement the equals/hashcode methods.

This way if you have your objects managed by the Persistence context will have one and only one instance of an object that represents a single row in the database.

Mark
 
Joseph Sweet
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you

Now I got it.

Now I can see that the thing that made it look so confusing was the fact that they used the term "persistent identity" in two different meanings:
First as a noun, the primary key value of the instance.
And then as an action, the act of comparing two instances by using the equals() method on their PK objects (or their equivalent wrapper objects if the PK are primitives).

But I think you did not phrase it correctly. You wrote: "if and only if pk of the object .equals() the pk of the record in the database."
But in order to verify "persistent identity", Hibernate does not do equals() between the pk of the object and the pk of the record in the db. The record in the db is not a Java object at all so it cannot be an argument of equals(). The "persistent identity" takes place (just like the Java identity) between two instances. So in order to verify "persistent identity" between two instances, Hibernate calls equals() between their PKs.
What Hibernate guarantees is that for two persistent instances, "persistent identity" is true if and only if instance1==instance2. Which is going to prevent having two persistent instances with the same value of PK only if we override the PK's equals() & hashCode().
[ November 13, 2007: Message edited by: Joseph Sweet ]
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Actually that is exactly what I was saying, is that Hibernate uses == in the persistence context, but say you have a detached object that you want to have the session manage (aka persistence context), and lets say you already have an object that has the same pk, meaning they represent the same row in the database, but if you ran a == b it would return false. That is why you need to implement the equals method so that Hibernate can merge the detached object and return one single object so that == will return true, which Hibernate needs.



Mark
 
Willie Smits increased rainfall 25% in three years by planting trees. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic