Когда вы обновляете / удаляете свой объект, на уровень кэширования отправляется уведомление, чтобы отразить эти изменения.
Ключ кеша может даже транслироваться на другой сервер, поэтому он должен нести достаточно полезной нагрузки, чтобы предоставить удаленному концу достаточно информации, чтобы очистить соответствующую запись. Но с другой стороны, он не может быть слишком большим, чтобы максимизировать пропускную способность.
Если вы включите отладку, вы увидите следующую структуру (она может различаться в зависимости от типа вашего постоянного объекта, идентификатора - составного или нет и т. Д.):
cacheKey = {org.hibernate.cache.CacheKey}
|- key = {your.own.serializable.class}
|- type = {org.hibernate.type.ComponentType}
| |- typeScope = {org.hibernate.type.TypeFactory$TypeScopeImpl}
| | |- factory = {org.hibernate.impl.SessionFactoryImpl}
| |- propertyNames = {...}
| |- propertyTypes = {...}
| |- propertyNullability = {...}
| |- propertySpan = 2
| |- cascade = {...}
| |- joinedFetch = {...}
| |- isKey = true
| |- tuplizerMapping = {...}
|- entityOrRoleName = {java.lang.String} "my.Entity"
|- entityMode = {org.hibernate.EntityMode}
|- hashCode = 588688
Как видите, ключ кеша Hibernate хранит информацию об имени класса, типе идентификатора и т. Д. Если у вас есть два разных типа, они будут сопоставлены с двумя разными ключами кеша, следовательно, ваша проблема.
Чтобы исправить это, вы можете создать классы DAO для обеих сущностей и гарантировать, что все вызовы для сохранения этих сущностей проходят только через них и больше нигде. Затем в методе _2 _ / _ 3_ обеих записей просто загружайте и вытесняйте другую сущность.
Другой вариант - использовать перехватчики, которые могут помочь достижение той же функциональности, но, на мой вкус, путь DAO чище.
person
mindas
schedule
29.10.2012