openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1328) Move cacheable class configuration to ClassMetaData
Date Thu, 12 Nov 2009 04:41:39 GMT


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:
>             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.

View raw message