[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3952) Enabling second level caching at runtime

[Gail Badner (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33673#action_33673 ] 

Gail Badner commented on HHH-3952:
----------------------------------

https://jira.jboss.org/jira/browse/JBPAPP-2095

> Enabling second level caching at runtime
> ----------------------------------------
>
>                 Key: HHH-3952
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3952
>             Project: Hibernate Core
>          Issue Type: New Feature
>          Components: caching (L2)
>            Reporter: Galder Zamarreno
>
> To be able to extend rolling upgrade strategies such as the one explained in http://www.jboss.org/community/docs/DOC-10910 
> to situations where 2nd level cache is used, some kind of dynamic switch for 2nd level cache would be required.
> The requirement comes from the fact that while the old cluster is running, users could update entities in the 2nd level cache after
> these entities have been read and loaded into the 2nd level cache in the new cluster. Since the old cluster and the new cluster
> does not communicate directly, invalidation messages from the old cluster would not be received by the new cluster and hence, 
> the new cluster could be interacting with stale data.
> The most sensible thing here IMO would be to start the new cluster with 2nd level cache disabled and at some point, when the old
> cluster has been completely shut down, turn it on again. This would require exposing some kind of control to be able to do the 
> switch. for example via JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira