public final class RemoveFromMapSpaceEntryMutator extends SpaceEntryPathMutator
Constructor and Description |
---|
RemoveFromMapSpaceEntryMutator() |
RemoveFromMapSpaceEntryMutator(String path,
Serializable key) |
Modifier and Type | Method and Description |
---|---|
Object |
change(MutableServerEntry entry)
Changes an entry.
|
Serializable |
getKey() |
String |
getName() |
void |
readExternal(ObjectInput in) |
void |
toText(Textualizer textualizer) |
void |
writeExternal(ObjectOutput out) |
getPath, toString
getChangeOperationResult
public RemoveFromMapSpaceEntryMutator()
public RemoveFromMapSpaceEntryMutator(String path, Serializable key)
public Object change(MutableServerEntry entry)
SpaceEntryMutator
MutableServerEntry
is wrapping the actual object which
is kept in space, therefore it is crucial to understand when a value is retrieved from the
entry it points to the actual reference in the data structure of the space. The content of
this reference should not be changed as it will affect directly the object in space and will
break data integrity, transaction and visibility scoping (transaction abort will not restore
the previous value). Changing a value should always be done via the MutableServerEntry.setPathValue(String, Object)
. Moreover, if you want to change a property
within that value by invoking a method on that object (e.g. if the value is a list, adding an
item to the list) first you must clone the fetched value first, and invoke the method on the
cloned copy otherwise, for the reason explained before, you will change the existing data
structure in the space without going the proper data update path and break data integrity.
Note that when using a replicated topology (e.g. backup space, gateway, mirror) the change operation itself is replicated (and *NOT* the modified entry). Hence, it is imperative that this method will always cause the exact same affect on the entry assuming the same entry was provided, for example it should not rely on variables that may change between executions, such as system time, random, machine name etc. If the operation is not structured that way, the state can be inconsistent in the different locations after being replicated When creating a custom change operation always have this in the back of your mind - "With great power comes great responsibility".
Following is an example that reads propertyA and set its value into propertyB and returns nothing.
public Object change(MutableServerEntry entry)
{
Object value entry.getPathValue("propertyA");
entry.setPathValue("propertyB", newValue);
return null;
}
Following is an example that adds the element 2 into an ArrayList that exists in the entry under a property named "listProperty", the result sent to client if requested is the size of the collection after the change, note that we clone the ArrayList before modifying it as explained before.
public Object change(MutableServerEntry entry)
{
ArrayList oldValue = (ArrayList)entry.getPathValue("listPropery");
if (oldValue == null)
throw new IllegalStateException("No collection instance exists under the given path
'listProperty', in order to add a value a collection instance must exist");
Collection newValue = (ArrayList)oldValue.clone()
newValue.add(2);
int size = newValue.size();
entry.setPathValue("listProperty", newValue);
return size;
}
change
in class SpaceEntryMutator
entry
- the entry to change.ChangeModifiers.RETURN_DETAILED_RESULTS
modifier.public void writeExternal(ObjectOutput out) throws IOException
writeExternal
in interface Externalizable
writeExternal
in class SpaceEntryPathMutator
IOException
public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException
readExternal
in interface Externalizable
readExternal
in class SpaceEntryPathMutator
IOException
ClassNotFoundException
public void toText(Textualizer textualizer)
toText
in interface Textualizable
toText
in class SpaceEntryPathMutator
public String getName()
public Serializable getKey()
Copyright © GigaSpaces.