Skip to content
Bluetape4k docs1.11

Entity, collection, and query caching

Latest stable Based on Bluetape4k release 1.11.0

Enabling the global second-level cache does not cache every entity. Add JPA @Cacheable and Hibernate @Cache to selected entities.

@Entity
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
class Product(
@Id @GeneratedValue
var id: Long? = null,
var name: String = "",
)

Start with read-heavy reference data. Frequently changing or strict-freshness entities can cost more in invalidation and stale windows than they save.

Caching an entity does not automatically cache its association collections. Annotate the collection itself.

@OneToMany(mappedBy = "department", cascade = [CascadeType.ALL])
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
val employees: MutableList<Employee> = mutableListOf()

The collection role is normally owner FQCN.property. Use the same role with containsCollection and evictCollectionData. A collection region stores membership while entity state may come from separate entity regions, so inspect both.

Enable query caching globally and mark each query cacheable.

hibernate.cache.use_query_cache=true
hibernate.generate_statistics=true
val people = session
.createSelectionQuery(
"select p from Person p where p.age > :age order by p.id",
Person::class.java,
)
.setParameter("age", 20)
.setCacheable(true)
.list()

Query caching stores result identifiers and relies on the update-timestamps region to invalidate results after related tables change. That timestamps region must not expire in Redis.

A new Session after rollback must observe the pre-transaction value. The 1.11.0 suite checks update and delete rollback behavior. Never edit Redis keys directly, because that bypasses Hibernate’s transaction-completion eviction flow.