anonymous wrote : 1. The internal code looks like crap. I don't know why you
didn't opt for a boolean flag like everything else, but so be it.
this flag also needs to be replicated within the cluster. Current implementation only
replicates node's underlying map, but it does not replicate Node's state. So the
reason of placing the info in the node map is for achieving replication. The nice solution
of replicating the metadata(i.e. node's data that is not placed in the underlying map)
requires API significant changes that are not acceptable within this release (e.g. the
cache loaders would also need to propagate metadata). I'll add an implementation doc
to state this.
anonymous wrote :
| 2. You added new methods to an interface that's potentially designed for clients
to implement.
See your point on this one - I don't think there is such a case, though.
anonymous wrote : 3. You add methods to a general interface that are specific to a
non-general concern.
I tend to agree that 'resident' is an non-general concern. As it has meaning only
in the scope of eviction. Phps move closer to the eviction layer? e.g.
Region.markNodeResident(Fqn, isResident);
| Region.isNodeResident(Fqn);
|
On the other hand this would make the API a bit cumbersome. IMO the info should be held
there, still. Others?
anonymous wrote :
| The point is, sure you can have "boolean get/set" methods. But why not add
to the interface instead:
| Code:
|
| void setProperty(Property p);
| | boolean getProperty(Property p);
|
This approach the advantages would be a) easiness of change and b) memory footprint.
a) at the cost of having the code less readable/strong typed. I prefer the strongly typed
approach.
b) As per a prev post don't reckon there is a memory gain
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090134#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...