[jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-798) Implement temporary EJBTHREE-795 workaround in EJB3 codebase

[William DeCoste (JIRA)]

     [ http://jira.jboss.com/jira/browse/EJBTHREE-798?page=all ]

William DeCoste updated EJBTHREE-798:
-------------------------------------

        Fix Version/s: EJB 3.0 RC9 - Patch 1
                           (was: EJB 3.0 RC10 - FD)
    Affects Version/s: EJB 3.0 RC9 - FD
                           (was: EJB 3.0 RC9 - Patch 1)

> Implement temporary EJBTHREE-795 workaround in EJB3 codebase
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-798
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-798
>             Project: EJB 3.0
>          Issue Type: Sub-task
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: EJB 3.0 RC9 - Patch 1
>
>
> Likely long term fix is to update the org.hibernate.cache.TreeCache class.  But, as a temporary workaround for the Stacks 1.1 release, I have implemented a new version of org.hibernate.cache.TreeCache in the EJB3 namespace, and updated TreeCacheProviderHook to use it.
> Updated version (o.j.ejb3.entity.JBCCache):
> Makes use of JBC's marshalling API to register a deployment's classloader with JBC and activate the relevant region when it is constructed.  When the destroy() method is called, the region is inactivated and the classloader unregistered.
> Exception to this are the special regions named "org.hibernate.cache.StandardQueryCache" and "org.hibernate.cache.UpdateTimestampsCache", which
> 1) should not have a particular classloader registered with them, as they may be used by multiple deployments.
> 2) should not be inactivated when a particular JBCCache instance is destroyed, as other deployments may be using them.
> UpdateTimestampsCache does not actually replicate any custom classes, so the special handling for it in JBCCache is just to make sure JBCCache doesn't break anything.
> StandardQueryCache does have the potential to replicate classes, but since no classloader can be registered with it's cache region, such a replication attempt will fail.  As a workaround, if the region's name is "org.hibernate.cache.StandardQueryCache", JBCCache will not replicate any queries placed in the region, but rather will only cache them locally.

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