Caching and concurrency management are tricky. If you have a cache that lives in memory but you have updates to the database that the objects originally came from, how are you going to make sure that the cached objects still reflect the contents of the database?
This really depends on what type of data you are dealing with. Data types that are mostly read (news, notices, articles) probably benefit from whatever caching you can provide, while areas of data that change a lot (shopping carts, server status records) probably won’t benefit from caching at all.

A cache concurrency strategy controls how the second-level cache is updated based on how often data is likely to change. Cache concurrency is set using the usage attribute in one of the following ways:

• With the @Cache annotation:
  @Cache(usage=CacheConcurrencyStrategy.READ_WRITE)
• In the cache-mapping configuration entry in the Hibernate configuration file hibernate.cfg.xml.
• In the <cache> property of a class or collection mapping file (hbm file).

Supported cache concurrency strategies are described in the following sections.

Note:- So if you are updating your database,it depends on your concurrency strategy whether it is going to be reflected in cache or not. 


Supported cache concurrency strategies are described in the following sections.

READ_ONLY

The READ_ONLY strategy works well for unchanging reference data. It can also work in use cases where the cache is periodically invalidated by an external event. That event can flush the cache, then allow it to repopulate.So this strategy is used when most operations on database are read only..So no change in cache is required.

READ_WRITE

The READ_WRITE strategy works well for data that changes and must be committed. READ_WRITE guarantees correct data at all times by using locks to ensure that transactions are not open to more than one thread.
If a cached element is created or changed in the database, READ_WRITE updates the cache after the transaction completes. A check is done for the element’s existence and (if the element exists) for an existing lock. The cached element is guaranteed to be the same version as the one in database.
Note, however, that Hibernate may lock elements before a transaction (update or delete) completes to the database. In this case, other transactions attempting to access those elements will miss and be forced to retrieve the data from the database.
Cache loading is done with checks for existence and version (existing elements that are newer are not replaced).

So if you have selected  READ_WRITE concurrency strategy,as soon as there is any update on database ,it updates the cache also so that cache reamins sync with database.

NONSTRICT_READ_WRITE

The NONSTRICT_READ_WRITE strategy is similar to READ_WRITE, but may provide better performance. NONSTRICT_READ_WRITE works well for data that changes and must be committed, but it does not guarantee exclusivity or consistency (and so avoids the associated performance costs). This strategy allows more than one transaction to simultaneously write to the same entity, and is intended for applications able to tolerate caches that may at times be out of sync with the database.
Because it does not guarantee the stability of data as it is changed in the database, NONSTRICT_READ_WRITE does not update the cache when an element is created or changed in the database. However, elements that are updated in the database, whether or not the transaction completes, are removed from the cache.
Cache loading is done with no checks, and get() operations return null for nonexistent elements.

TRANSACTIONAL

The TRANSACTIONAL strategy is intended for use in an environment utilizing the Java Transaction API (JTA) to manage transactions across a number of XA resources. This strategy guarantees that a cache remains in sync with other resources, such as databases and queues. Hibernate does not use locking for any type of access, but relies instead on a properly configured transactional cache to handle transaction isolation and data integrity