anchor.diff:  Most `Graph` implementations that `supportsTransactions` will implement an "automatic" `ThreadLocal` transaction, which means that when a read or write occurs after the `Graph` is instantiated a transaction is automatically started within that thread.  There is no need to manually call a method to "create" or "start" a transaction.  Simple modify the graph as required and call `graph.tx().commit()` to apply changes or `graph.tx().rollback()` to undo them.  When the next read or write action occurs against the graph, a new transaction will be started within that current thread of execution.
   
   When using transactions in this fashion, especially in web application (e.g. REST server), it is important to ensure that transaction do not leak from one request to the next.  In other words, unless a client is somehow bound via session to process every request on the same server thread, ever request must be committed or rolled back at the end of the request.  By ensuring that the request encapsulates a transaction, it ensures that a future request processed on a server thread is starting in a fresh transactional state and will not have access to the remains of one from an earlier request. A good strategy is to rollback a transaction at the start of a request, so that if it so happens that a transactional leak does occur between requests somehow, a fresh transaction is assured by the fresh request.
  +
  +TIP: The `tx()` method is on the `Graph` interface, but it is also available on the `TraversalSource` spawned from a `Graph`.  Calls to `TraversalSource.tx()` are proxied through to the underlying `Graph` as a convenience.
   
   Configuring
   ~~~~~~~~~~~
  
positive.code: A `Feature` implementation describes the capabilities of a `Graph` instance. This interface is implemented by vendors for two purposes:
  
    . It tells users the capabilities of their `Graph` instance.
    . It allows the features they do comply with to be tested against the Gremlin Test Suite (tests they don't comply with are "ignored").
  
  The following example in the Gremlin Console shows how to print all the features of a `Graph`:
  
  
negative.code: graph.tx().commit();
  ----
  
  The above code shows three vertices added to `graph` in three different threads: the current thread, `t1` and `t2`.  One might expect that by the time this body of code finished executing, that there would be three vertices persisted to the `Graph`.  However, given the `ThreadLocal` nature of transactions, there really were three separate transactions created in that body of code (i.e. one for each thread of execution) and the only one committed was the first call to `addVertex` in the primary thread of execution.  The other two calls to that method within `t1` and `t2` were never committed and thus orphaned.
  
  A `Graph` that `supportsThreadedTransactions` is one that allows for a `Graph` to operate outside of that constraint, thus allowing multiple threads to operate within the same transaction.  Therefore, if there was a need to have three different threads operating within the same transaction, the above code could be re-written as follows:
  
  