3

I'm kicking the tires on EclipseLink(2.3.0) and found something that seems severely wrong. The net of my problem is that when an Entity is returned from a shared cache hit, java.util.Date(and perhaps others) aren't copied as I would expect. This has some pretty nasty consequences as Date fields aren't immutable, and as such can't be shared.... but then again maybe I'm missing something? I'll note that I don't have any properties set, but I am using the -javaagent weaver in a JSE environment.

Test snippet:

// Setup
EntityManager em = emf.createEntityManager();
Person p = new Person(2);
java.util.Date d = new java.util.Date();
p.setDate(d);

em.getTransaction().begin();
em.persist(p);
em.getTransaction().commit();
em.close();

// Get a fresh em
EntityManager em1 = emf.createEntityManager();

Person p1 = em1.find(Person.class, p.getId()); // cache hit
java.util.Date d1 = p1.getDate();

assertFalse(p == p1); // Make sure we have different entities
// The next line fails! For some odd reason different Entities are sharing the same date.
assertFalse(d == d1); // make sure each Entity instance has different date instances
user1738358
  • 33
  • 2

1 Answers1

0

This is described in the EclipseLink docs here: http://wiki.eclipse.org/Introduction_to_EclipseLink_Application_Development_(ELUG)#Mutability

Short answer: most non serialized Basics are treated as immutable, but can be configured to be treated as mutable using the EclipseLink @Mutable annotation: http://eclipse.org/eclipselink/documentation/2.4/jpa/extensions/a_mutable.htm

Chris
  • 20,138
  • 2
  • 29
  • 43
  • Wow! That is completely counter intuitive and doesn't make much sense. – user1738358 Oct 11 '12 at 15:20
  • Even worse, my application behaves differently when the cache is enabled vs disabled?! – user1738358 Oct 11 '12 at 15:29
  • Maybe. From ORM though, tracking changes is expensive. It is more efficient if the date is immutable, since it is hard to tell when the date internals change otherwise - attribute change tracking can't be used when it is something internal to the attributes that has changed. Comparisons can use '==' and set the value in cached objects can can '=' if it is immutable. Without a shared cache, reading in the object multiple times means getting a new instance each time - with their own date instance. A shared cache reuses the same instance and its date object. – Chris Oct 12 '12 at 13:44
  • 1
    So you're saying that performance is more important than adhering documented APIs (Date and Calendar)? In my opinion, changing the definition (mutable vs immutable) of an object in a system to better support shortcomings in another implementation is 100% the wrong answer. I'm really stuck on the potential for cache vs no-cache having different behavior. Thanks for the links though! – user1738358 Oct 12 '12 at 15:23