You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2009/11/12 05:41:39 UTC

[jira] Commented: (OPENJPA-1328) Move cacheable class configuration to ClassMetaData

    [ https://issues.apache.org/jira/browse/OPENJPA-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776834#action_12776834 ] 

Pinaki Poddar commented on OPENJPA-1328:
----------------------------------------

ClassMetaData is not the right place for holding cache information, imo.
Firstly, for practical use cases, caches are hardly partitioned by types. 
Secondly, the cache eligibility logic may be more user configurable than assigning all instances of a type statically to a single named cache.

DataCacheManager seems to be much better abstraction to implement cache assignment to instances (even if only based on types).
These changes are incorporated in trunk for OPENJPA-1334.

> Move cacheable class configuration to ClassMetaData
> ---------------------------------------------------
>
>                 Key: OPENJPA-1328
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1328
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: datacache
>    Affects Versions: 1.2.0, 1.2.1
>            Reporter: Jody Grassel
>            Assignee: Michael Dick
>         Attachments: OpenJPA_1.2.x_OJ1328.patch
>
>
> I'm proposing to move the cacheable class configuration processing from the datacache classes to ClassMetaData.  The feature, introduced in OPENJPA-1045, effectively works by returning null for ClassMetaData.getDataCacheName(), where classes which should not be cached return null, otherwise the name of the datacache they may be cached by is returned.  
> THe problem is that some third party datacache plugins are not reentrant, and the existing ClassMetaData.isCacheable() makes use of the method call getRepository().getConfiguration().getDataCacheManagerInstance().  This invokes the initialization of the datacache, which may result in further initialization/copying of CMD objects, which reenter the isCacheable() method.  If a third party datacache plugin is not reentrant safe, this can cause a failure in the form of Exceptions or hung threads.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.