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)
BrooklynStoragegetReference in interface BrooklynStoragepublic <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 BrooklynStoragepublic <K,V> java.util.concurrent.ConcurrentMap<K,V> getMap(java.lang.String id)
BrooklynStorageMap.keySet() etc will iterate over a snapshot view of the
 contents.getMap in interface BrooklynStoragepublic void remove(java.lang.String id)
BrooklynStorageremove in interface BrooklynStoragepublic void terminate()
BrooklynStorageterminate in interface BrooklynStoragepublic boolean isMostlyEmpty()
BrooklynStoragenot meant for use outwith tests
isMostlyEmpty in interface BrooklynStoragepublic java.util.Map<java.lang.String,java.lang.Object> getStorageMetrics()
getStorageMetrics in interface BrooklynStoragepublic java.lang.String toString()
toString in class java.lang.Object