net.corda.node.utilities / AbstractJDBCHashMap / <init>

# <init>

`AbstractJDBCHashMap(table: T, loadOnInit: Boolean = false, maxBuckets: Int = 256)`

A base class for a JDBC table backed hash map that iterates in insertion order by using an ever increasing sequence number on entries. Iterators supports remove() but entries are not really mutable and do not support setValue() method from MutableMap.MutableEntry.

You should only use keys that have overridden Object.hashCode and that have a good hash code distribution. Beware changing the hashCode() implementation once objects have been persisted. A process to re-hash the entries persisted would be necessary if you do this.

Subclasses must provide their own mapping to and from keys/values and the database table columns, but there are inherited columns that all tables must provide to support iteration order and hashing.

The map operates in one of two modes.

1. loadOnInit=true where the entire table is loaded into memory in the constructor and all entries remain in memory, with only writes needing to perform database access.

2. loadOnInit=false where all entries with the same key hash code are loaded from the database on demand when accessed via any method other than via keys/values/entries properties, and thus the whole map is not loaded into memory. The number of entries retained in memory is controlled indirectly by an LRU algorithm (courtesy of LinkedHashMap) and a maximum number of hash "buckets", where one bucket represents all entries with the same hash code. There is a default value for maximum buckets.

All operations require a databaseTransaction to be started.

The keys/values/entries collections are really designed just for iterating and other uses might turn out to be costly in terms of performance. Beware when loadOnInit=true, the iterator first sorts the entries which could be costly too.

This class is not thread safe.

TODO: consider caching size once calculated for the first time. TODO: buckets just use a list and so are vulnerable to poor hash code implementations with collisions. TODO: if iterators are used extensively when loadOnInit=true, consider maintaining a collection of keys in iteration order to avoid sorting each time. TODO: revisit whether we need the loadOnInit==true functionality and remove if not.