EclipseLink (2.3.0)에서 타이어를 차고 심각한 오류가있는 것으로 나타났습니다. 내 문제의 그물은 엔티티가 공유 캐시 히트에서 반환 될 때 java.util.Date
(및 다른 것들)은 예상대로 복사되지 않는다는 것입니다. 이것은 날짜 필드가 불변하지 않기 때문에 꽤 심한 결과를 낳습니다. 따라서 공유 할 수 없기 때문에 .... 그런데 다시 뭔가를 놓치겠습니까? 저는 속성이 설정되어 있지 않지만 JSE 환경에서는 -javaagent
위버를 사용하고 있습니다.java.util.Date 필드에서 예기치 않은 EclipseLink 공유 캐시 동작
테스트 조각이 여기는 EclipseLink의 문서에 설명되어
// 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
더 나빠질 때, 내 응용 프로그램은 캐시가 활성화되었을 때와 작동하지 않을 때 다르게 작동합니다. – user1738358
아마. ORM에서 추적 변경은 비용이 많이 듭니다. 날짜가 변경 될 수 없다면 내부 날짜가 변경 될 때를 알기가 어렵 기 때문에 날짜가 변경되면 더 효율적입니다. 속성 변경 추적은 변경된 속성의 내부 항목 일 때 사용할 수 없습니다. 비교는 '=='를 사용할 수 있고 캐시 된 객체의 값을 설정할 수 있습니다. 불변 인 경우 can = '할 수 있습니다. 공유 캐시가 없으면 객체를 여러 번 읽는 것은 매번 새로운 인스턴스를 가져 오는 것을 의미합니다. 공유 캐시는 동일한 인스턴스와 날짜 객체를 재사용합니다. – Chris