anchor.diff:      bind *:8080
       stats enable
   ----
  +
  +
  
positive.code: When operating in HA mode, Neo4j does not make open transactions available across all nodes in the cluster.
  This means we must bind every request within a specific transaction to the same node in the cluster, or the commit will fail with `404 Not Found`.
  
  
  [[reference-configuration-readwrite]]
  == Read-only transactions
  
  As of version 1.1.1 the OGM does not distinguish between WRITE transactions and READ-ONLY transactions.
  We cannot therefore bind read-only transactions to slaves and write transactions to master.
  A future version will address this deficiency, but in the meantime the only way to ensure that everything works as expected is to direct every transaction to master.
  There are a couple of ways to to achieve this.
  
  
  [[reference-configuration-staticbinding]]
  == Static binding to a designated master
  
  
  === Example cluster:
  
  . master:    192.168.0.55
  . slave1:    192.168.0.56
  . slave2:    192.168.0.67
  
  .OGM Binding to master IP address
  [source, java]
  ----
  Components.driver().setURI("http://192.168.0.55:7474");
  ----
  
  [NOTE]
  ====
  We don't really recommend this approach, except for testing purposes and non-critical deployments.
  Firstly, it will only work if you always bring up the designated master first, and secondly, if the master goes down all subsequent transactions will fail until it is restarted.
  In HA mode, the cluster is able to elect a new master when this happens, but as of the current version of the OGM, there is no mechanism for querying the cluster to identify the current master.
  The solution in this case is to use a load balancer such as HAProxy that can do this for us.
  This is described in the next section.
  ====
  
  
  [[reference-configuration-haproxy]]
  == Dynamic binding via a load balancer
  
  In the Neo4j HA architecture, a cluster is typically fronted by a load balancer.
  The following example shows how to configure your application and set up HAProxy as a load balancer to route all requests to whichever machine in the cluster is currently identified as the master.
  Since only one machine can ever be the elected master, this should work exactly as we would like.
  Furthermore, should the elected master fail, a new server will be elected from the cluster as master and HAProxy will automatically route transactions to this server.
  
  
  === Example cluster fronted by HAProxy
  
  
negative.code: 
  frontend http-in
      bind *:80
      acl write_hdr hdr_val(X-WRITE) eq 1
      use_backend neo4j-master if write_hdr
      default_backend neo4j-cluster
  
  backend neo4j-cluster
      balance roundrobin
      # create a sticky table so that requests with a transaction id are always sent to the correct server
      stick-table type integer size 1k expire 70s
      stick match path,word(4,/)
      stick store-response hdr(Location),word(6,/)
      option httpchk GET /db/manage/server/ha/available
      server s1 10.0.1.10:7474 maxconn 32
      server s2 10.0.1.11:7474 maxconn 32
      server s3 10.0.1.12:7474 maxconn 32
  
  backend neo4j-master
      option httpchk GET /db/manage/server/ha/master
      server s1 10.0.1.10:7474 maxconn 32
      server s2 10.0.1.11:7474 maxconn 32
  