2015-06-19 29 views
6

Validation örneğinin Koleksiyona bir Step örneğinde eklendiği bir sorun yaşıyorum. şöyle Bildirgesi:Önbellek tutarsızlığı - Varlık her zaman önbelleğe alınmış Koleksiyonda kalıcı değil

Aşama sınıfı:

@Entity 
@Table 
@Cacheable 
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
public class Step extends AbstractEntity implements ValidatableStep { 

    @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true) 
    @JoinColumn(name = "step_id", nullable = false) 
    @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
    private Set<Validation> validations = new HashSet<>(); 

    @Override 
    public void addValidation(Validation validation) { 
     // do some stuff 
     ... 
     // add validation instance to collection 
     getValidations().add(validation); 
    } 

} 

Doğrulama sınıfı:

@Entity 
@Table 
@Cacheable 
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
@NoArgsConstructor(access = AccessLevel.PROTECTED) 
public class Validation extends AbstractEntity { 
    //some properties 
} 

Her iki sınıf uygulanan bir READ_WRITE stratejisiyle Cacheable bulunmaktadır. Validation s tek yönlü Toplama da aynı strateji ile önbelleğe alınır.

addValidation(new Validation('userName')); çağrısını yapan bir okuma-yazma işlemi tamamlandığında, yeni Validation sonraki bir salt okunur işlemde görünür olacaktır. Garip olan şey, bazen işe yarıyor ve bazen işe yaramıyor ...

İlk işlem her zaman başarılı; veritabanı ve Step'un versiyon özelliğinde (iyimser kilitleme kuklaları için) artırılan yeni geçerliliğin arttığını görüyoruz. Bu garip (ve rastgele) davranışlarını neyin neden

hibernate.cache.use_second_level_cache = true 
hibernate.cache.use_query_cache = true 
hibernate.cache.region.factory_class = org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory 
hibernate.cache.provider_configuration_file_resource_path = classpath:ehcache.xml 
net.sf.ehcache.hibernate.cache_lock_timeout = 10000 

konusunda fikrin: Fakat bazen 2 okuma işlemi aşağıdaki gibi

Bizim hazırda önbelleğe alma yapılandırma olduğunu ... boş Validation Koleksiyonu ile Step örneğini içeriyor?

cevap

1

Hibernate Collection CacheHibernate Collection Cache her zaman varolan girdileri geçersiz kılar ve hem Varlık hem de Toplama önbellekleri verileri güncelleştirirken AbstractReadWriteEhcacheAccessStrategy, yani soft-lock is acquired'u paylaşır.

Tek yönlü bire çoktan bir ilişki kullandığınız için, bir Validation tablosu ve bir Step_validation bağlantı tablosuyla da sonuçlanacaksınız. Bir Doğrulama eklediğinizde/kaldırdığınızda, iki tabloya vurmanız gerekir ve bu da daha az verimlidir.

Sana Validation varlıktaki @ManyToOne tarafını eklemeyi önermek ve içine @OneToMany tarafını çevirin eşlenen-by koleksiyonu a:

@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true, mappedBy = "step") 
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
private Set<Validation> validations = new HashSet<>(); 
+0

Aslında bir bağlantı tablo yok. Doğrulama sadece Step'e yabancı bir tuşa sahiptir. Yani bir add/remove sadece bir tablo tetiklemelidir. Her neyse, ilişkiyi iki yönlü yaptım ve bu hile yaptı! Ancak, neden 2. düzey önbellek neden çift yönlü bir ilişki gerektirdiğini anlamıyorum? Benim uygulamam tek yönlü olanlarla doludur (çünkü bi her zaman anlamlı değildir). Bu, bütün ilişkileri yeniden gözden geçirmem gerektiği anlamına mı geliyor? Tüm koleksiyonlarda bir NONSTRICT_READ_WRITE veya READ_WRITE önbellekleme stratejisi kullanıyorum ... – user2054927

+0

'Step' dernekteki ana ve Val Validation' Child'dır. Ebeveyn-Çocuk ilişkisinde, Ebeveyn bire-çok tarafıdır ve aynı zamanda haritalanması da daha iyidir. Çoğu zaman, bunu bire-çok tarafını kaldırmayı ve yalnızca bire bir ilişkiyi bırakmayı gerektiren tek yönlü bir ilişkiye dönüştürebilirsiniz. Tek yönlü bire-bir ilişki her zaman bir bağlantı tablosu kullanır ve bu çok pratik değildir. Bu açıklama için –

+0

Thx! – user2054927

İlgili konular