[JBoss JIRA] (ISPN-2192) Allow using Distributed Execution against any cache (not just clustered caches)
by Randall Hauch (JIRA)
Randall Hauch created ISPN-2192:
-----------------------------------
Summary: Allow using Distributed Execution against any cache (not just clustered caches)
Key: ISPN-2192
URL: https://issues.jboss.org/browse/ISPN-2192
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 5.1.2.FINAL
Reporter: Randall Hauch
Assignee: Manik Surtani
Priority: Critical
It is often desirable to process all entries in a cache, and there is no reliable and consistent way to do that for any cache.
If a cache is clustered, then map-reduce can be used (although IIUC it currently doesn't guarantee to process non-materialized entries for caches that have a cache store) and distributed execution can be used (IIUC this will be called for all keys owned by the cluster node). However, neither of these work on local caches.
If a cache is local and there is no cache store, then apparently {{keySet()}} does work and allows a client to iterate over the keys in the local cache. However, if the local cache is configured to have a cache store, then the {{keySet()}} method will return only the keys for the materialized entries and does not return all of the keys in the cache. Of course, if a local cache does have a cache store, then its possible to obtain the keys using {{CacheLoader.loadAllKeys(...)}} (obviously this is probably not something a client should do).
In short, it should be possible to use Distributed Execution against any cache, regardless of its configuration. (Ideally, it would be possible for Map-Reduce to also be used against any cache.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-31) JPA based cache store
by Ray Tsang (JIRA)
[ https://issues.jboss.org/browse/ISPN-31?page=com.atlassian.jira.plugin.sy... ]
Ray Tsang updated ISPN-31:
--------------------------
Attachment: infinispan-cachestore-jpa.zip
Implemented a simple JPA cache store.
- Cache using JPA Cache Store can only store mapped JPA entity as value
- JPA entity is limited to one ID field marked by @Id, w/ primitive, String, or Number type, without @GeneratedValue
- Cache key must equal to the entity ID
> JPA based cache store
> ---------------------
>
> Key: ISPN-31
> URL: https://issues.jboss.org/browse/ISPN-31
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Manik Surtani
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
> Attachments: infinispan-cachestore-jpa.zip
>
>
> Store that uses JPA for persistence
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-2495) Replication on startup not reliable
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2495:
----------------------------------
Summary: Replication on startup not reliable
Key: ISPN-2495
URL: https://issues.jboss.org/browse/ISPN-2495
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta3
Reporter: Thomas Fromm
Assignee: Mircea Markus
Priority: Blocker
Attachments: 2ND.log
Situation: REPL cache with Cache Loader and ~500k entries and preload = true
Problem: 1st node starts and the startup (until cache loaded all entries and so on) takes lets say 2min. When starting the 2nd node after e.g. 30s, then state is requested, but contains no results. cache loader is also not used, since its not the 1st node. Log from 2nd node is attached.
So I've REPL cache over two (or more ) nodes, where only the 1st node contains the entries.
When starting all other nodes later, then state transfer works and the data gets replicated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years