There is a JIRA issue
"Partitioned Cache", which is asssigned to the release 2.0.0.GA.
It is now closed with resolution "Deferred" and with a comment:
"Manik Surtani [23/Feb/06 08:53 AM]
May not be a need, gravitation of data in buddy replication will solve this."
Buddy replication with gravitation of data doesn't replace partitioning.
For example, if we have three nodes:
A, Data:A, Backup:C
B, Data:B, Backup:A
C, Data:C, Backup:B
user on node C can not get data from node A.
So sticky sessions are required. This pre-requisite is mandatory.
But sometimes it is not possible to have sticky sessions. So real partitioning is needed, where:
1) there is a hash function which returns node id by passed key of entry, each node knows this function
2) the data is stored in fixed (configurable) number of nodes, (for example, on two nodes - primary and backup)
3) when client performs get/put operations, cache calls hash function and request comes to corresponding node (local or remote)
4) when new node joins the cluster or exising node exits the cluster, data is redistributed
My question is: Why is the development of partitioning in JBossCache frozen?
It wasn't frozen, but deferred for a later release since we did not have the resources or time to focus on it.
To be honest, marking it as deferred was probably wrong. I have reopened it and targetted it for a future release (way into the future) for now; it very certainly is on the roadmap, just not for another 6 - 8 months.