Don't create LockElement unnecessarily. This drastically reduces object churn under normal operation, as LockableWIndow.lock() is a common operation.
Merge pull request #2559 from neo4j/poolablelocks

Don't create LockElement unnecessarily
Splits MultiPaxosContext in the same manner as in 2.0+
Merge pull request #2569 from jakewins/1.9-paxossplit

1.9 paxossplit
Backport: Speed up consistency checking of non-constraint indexes

This improves the time complexity for consistency checking of normal non-constraint schema
indexes from an O(n^2) to O(n).

This is especielly noticable when many nodes are indexed by the same
<label,propertyKey,propertyValue> tuples.

The old code would go over all the nodes that were supposed to be indexed, and then for
each of those nodes, do a lookup on the propertyValue, and then iterate through the result
set of that look up, looking for the nodeId in question. This is obviously an oh-n-squared
amount of work, if all the nodes are indexed with the same property value.

The new code do an exact lookup for the combined <nodeId,propertyValue> in the given
<label,propertyKey> index. For our purpose, we consider this a constant cost, and so our
work now ends up being oh-n.

Conflicts:
	community/kernel/src/test/java/org/neo4j/kernel/impl/api/index/inmemory/UniqueInMemoryIndexReader.java
Merge pull request #2578 from chrisvest/2.0-backport-faster-consistency-checker

2.0 backport faster consistency checker
Do a store copy on join when there are no log files for the latest transaction.

I tried writing a test for this, but SwitchToSlave is hard to write tests for,
so the fix is provided without one.
Fix GC overhead of XidImpl

- Only allow equality of XidImpl instances, not the Xid interface,
  reasoning being that hashCode cannot be equal to other xid impls since
  there is no standard, and getting a xid that isn't a xidimpl is an error,
  since the xids come from our tx manager, we do not manage other xids.

- Don't copy the branchID and globalId arrays on every equaylity check
Updates changelogs for 1.9.8
Fixed compile error. Not on Java 7 just yet.
Merge branch '1.9-maint' into 1.9-merge

Conflicts:
	enterprise/cluster/CHANGES.txt
	enterprise/cluster/src/main/java/org/neo4j/cluster/MultiPaxosServerFactory.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/BiasedWinnerStrategy.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/AbstractContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/AcceptorContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/ClusterContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/CommonContextState.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/ElectionContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/HeartbeatContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/LearnerContextImpl.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/MultiPaxosContext.java
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/ProposerContextImpl.java
	enterprise/ha/CHANGES.txt
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/cluster/HighAvailabilityModeSwitcher.java
Allow instances to restart at election version 0. This will happen if an instance crashes and rejoins.

Conflicts:
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/atomicbroadcast/multipaxos/context/ClusterContextImpl.java
Fixed list parsing on empty string
On bind, update the ClusterConfiguration as well
Ensure UniquenessConstraint created by BatchInserter are consistent.

A UniquenessConstraint consists of two records in the Schema store, one
representing the constraint, and one representing the backing index. The
backing index should reference the constraint as its owning constraint,
and the constraint should reference that it owns the index. The
BatchInserter failed to set up this relationship properly since it
generated the id for the constraint record twice.
This commit fixes that issue.
Typo in installation instructions.
Fix so that read-only transactions actually do have transaction state
Merge pull request #2606 from rickardoberg/readonlytxfix

Fix so that read-only transactions actually do have transaction state
Merge pull request #2603 from thobe/2.0-consistent-batch-constraints

[2.0] Ensure UniquenessConstraint created by BatchInserter are consistent.
Fix problem that could lead to missing index constraints in HA

Here's the thing: When we insert a new record into a store, we do the write immediately to grab
the id associated with that particular location in the file. When we update a record, we keep
the change around in memory until the stores are flushed, which only happens on log rotation.

When we create a new constraint, we first create the associated constraint index, and start off
the index population job. At this point, the owner field for this constraint index is empty.
When the population completes and our transaction commits, we then create the related
constraint rule, and update the index constraint record such that its owner fields references
this newly created constraint rule. This is of course all written to the transaction log, and
applied to the store files with as little actual IO as possible. Like I said above, we only
flush the store files when we rotate the log.

Because we want really fast access to the small bits of information that is our schema store,
we load up and cache the entire schema store when the database starts up. This schema cache is
then kept in sync with the schema store, when schema-mutating transactions are committed and
applied.

When we start up, we do recovery (if needed) and then we do our post-recovery. In our post-
recovery, we seek out all constraint indexes that have no owning constraint, and then we drop
them. We do this because we might have crashed in between creating the index, and creating
and committing the associated constraint. If that happens, then the constraint ended up never
being committed, and so we don't need the index that was created for it.

When we do a mode switch, from leader to follower or follower to leader, we *partially* restart
the database. This means that we don't do any recovery, and we don't attempt to rotate the log.
We do still do our post-recovery, however, and this is look through all our constraint rules,
and drop indexes that don't have any owning constraints.

Now, it somehow happened, that we occasionally had schema-mutations applied to our schema store,
but not to the schema cache. Specifically, the schema cache would containt constraint indexes
that had an empty owner field, while the store had been correctly updated. The new leader
instance of the cluster would then inject a transaction that dropped all the constraint indexes,
and push that transaction out to the followers.

The constraint would then be rendered broken. So broken, in fact, that it couldn't even be
dropped, since dropping a constraint also implies dropping its index, but the index can no
longer be read from the schema store because it has been deleted.

This commit fixes this problem, by reloading the schema cache when we have a
follower-to-leader mode switch.
Significantly reduce the probability of the StatisticsCollectorTest failing spuriously

With the added data collection runs, the collected statistics seems to become precise enough
that the test doesn't fail after hundreds of thousands of invocatinos.