public class BrooklynStorageImpl extends java.lang.Object implements BrooklynStorage
Constructor and Description |
---|
BrooklynStorageImpl(DataGrid datagrid) |
Modifier and Type | Method and Description |
---|---|
DataGrid |
getDataGrid()
Returns the DataGrid used by this BrooklynStorageImpl
|
<K,V> java.util.concurrent.ConcurrentMap<K,V> |
getMap(java.lang.String id)
Creates a map backed by the storage-medium.
|
<T> Reference<java.util.List<T>> |
getNonConcurrentList(java.lang.String id)
Creates a list backed by the storage-medium.
|
<T> Reference<T> |
getReference(java.lang.String id)
Creates a reference to a value, backed by the storage-medium.
|
java.util.Map<java.lang.String,java.lang.Object> |
getStorageMetrics() |
boolean |
isMostlyEmpty()
asserts that some of the storage containers which should be empty are empty;
this could do more thorough checks, but as it is it is useful to catch many leaks,
and the things which aren't empty it's much harder to check whether they should be empty!
|
void |
remove(java.lang.String id)
Removes the data stored against this id, whether it is a map, ref or whatever.
|
void |
terminate()
Terminates the BrooklynStorage.
|
java.lang.String |
toString() |
public BrooklynStorageImpl(DataGrid datagrid)
public DataGrid getDataGrid()
public <T> Reference<T> getReference(java.lang.String id)
BrooklynStorage
getReference
in interface BrooklynStorage
public <T> Reference<java.util.List<T>> getNonConcurrentList(java.lang.String id)
BrooklynStorage
Reference<List<String>> ref = storage.<String>createNonConcurrentList("myid");
List<String> newval = ImmutableList.<String>builder().addAll(ref.get()).add("another").builder();
ref.set(newval);
TODO Aled says: Is getNonConcurrentList necessary?
The purpose of this method, rather than just using
Reference ref = getReference(id); ref.set(ImmutableList.of())
is to allow control of the serialization of the things inside the list
(e.g. switching the Location object to serialize a proxy object of some sort).
I don't want us to have to do deep inspection of every object being added to any map/ref.
Feels like we can use normal serialization unless the top-level object matches an
instanceof for special things like Entity, Location, etc.
Peter responds:
What I'm a bit scared of is that we need to write some kind of meta serialization mechanism
on top of the mechanisms provided by e.g. Hazelcast or Infinispan. Hazelcast has a very
extensive serialization library where you can plug in all kinds of serialization mechanisms.getNonConcurrentList
in interface BrooklynStorage
public <K,V> java.util.concurrent.ConcurrentMap<K,V> getMap(java.lang.String id)
BrooklynStorage
Map.keySet()
etc will iterate over a snapshot view of the
contents.getMap
in interface BrooklynStorage
public void remove(java.lang.String id)
BrooklynStorage
remove
in interface BrooklynStorage
public void terminate()
BrooklynStorage
terminate
in interface BrooklynStorage
public boolean isMostlyEmpty()
BrooklynStorage
not meant for use outwith tests
isMostlyEmpty
in interface BrooklynStorage
public java.util.Map<java.lang.String,java.lang.Object> getStorageMetrics()
getStorageMetrics
in interface BrooklynStorage
public java.lang.String toString()
toString
in class java.lang.Object