[
https://issues.jboss.org/browse/ISPN-312?page=com.atlassian.jira.plugin.s...
]
Pete Muir commented on ISPN-312:
--------------------------------
I propose two APIs for controlling this. The first, where you have control of the key
class you can annotate the key class directly, either providing a static group:
{code}
@Group("com.acme.hr") class Employee { ... }
{code}
or a dynamic group
{code}
@Group class Employee {
String group;
...
@Group
String getGroup() {
return group;
}
}
{code}
If an annotation is used at class level with the value attribute provided, then this will
be used as the group id. If no value attribute is specified, then there must be a method
annotated @Group with no attribute, there must be no arguments to the method and the
return type of the method must be String. Whenever the group of the key needs identifying
then this method will be called. The impl will cache the annotation information in order
to not incur large amounts of runtime overhead on annotation inspection.
In the case where the key class cannot be modified, then a group generator can be
registered using Infinispan Configuration, which should implement the GroupGenerator
interface:
{code}
interface GroupGenerator<T> {
String generateGroup(T key);
}{code}
For example, a group generator for String keys which encode the group info in their
namespace might look like:
{code}
class StringGroupGenerator implements GroupGenerator<String> {
Pattern namespacePattern;
// Initialize the pattern e.g. match com.acme.hr from any key
com.acme.hr.<personName>
String generate(String key) {
return namespacePattern.split(key)[0];
}
}
{code}
Obviously the code above is not very safe, but serves as a basic example for now ;-)
Ability to group data entries
-----------------------------
Key: ISPN-312
URL:
https://issues.jboss.org/browse/ISPN-312
Project: Infinispan
Issue Type: Feature Request
Components: Core API, Distributed Cache, Eviction, Locking and Concurrency
Affects Versions: 4.0.0.Final, 4.1.0.Final
Reporter: Mindaugas Žakšauskas
Assignee: Pete Muir
Priority: Minor
Labels: cache, colocation, group, grouping
Fix For: 5.1.0.BETA1
This is a spin-off from
http://lists.jboss.org/pipermail/infinispan-dev/2009-December/001968.html.
The requested feature would allow distinct entries to be assigned to custom arbitrary
groups. Later in time those groups could be flushed on demand without any knowledge of
entry keys.
This feature exists in other open source cache library, see:
http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/base/Cac...
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira