anchor.diff:  link:https://issues.apache.org/jira/browse/TINKERPOP-2472[TINKERPOP-2472],
   link:http://tinkerpop.apache.org/docs/3.5.0/dev/provider/#_supporting_gremlin_net_io[Documentation for custom JSON serialization with Gremlin.NET]
   
  +==== Transaction Improvements
  +
  +The TinkerPop Transaction API and its related features have not changed much since TinkerPop 3.x was initially
  +released. Transactions have remained a feature for embedded use cases and script execution (where supported) even in
  +the face of the rise of remote graph use cases. With the varying contexts that exist for how and when transactions can
  +be used, it has led to a fair bit of confusion.
  +
  +For 3.5.0, TinkerPop introduces a change in approach to transactions that has the goal of unifying the API and features
  +for all use cases, while addressing the more current state of the graph ecosystem which has shifted heavily toward
  +remote communication and more diverse programming language ecosystems beyond the JVM.
  +
  +NOTE: The old transaction API remains intact in 3.5.0, so this version should be backward compatible with the old
  +model for embedded transactions. Migrating to the new model would be preferred at this point, but nothing (with the
  +exception of the `Transaction#createdThreadedTransaction()` method) has been officially deprecated as the API itself
  +is technically still relevant.
  +
  +The new model for transactions looks like this:
  +
  +[source,groovy]
  +----
  +g = traversal().withEmbedded(graph)
  +// or
  +g = traversal().withRemote(conn)
  +
  +tx = g.tx() // create a Transaction object
  +gtx = tx.begin()  // spawn a GraphTraversalSource from the Transaction
  +assert tx.isOpen() == true
  +gtx.addV('person').iterate()
  +gtx.addV('software').iterate()
  +tx.commit() // alternatively you could explicitly rollback()
  +assert tx.isOpen() == false
  +
  +// it is still possible to use g, but gtx is "done" after it is closed so use
  +// tx.begin() to produce a new gtx instance for a fresh transaction
  +assert 2 == g.V().count().next()
  +----
  +
  +The first important point to take away here is that the same transaction code will work for either embedded or remote
  +use cases. The second important point is that for remote cases, transaction support with bytecode is a wholly new
  +feature, which was implemented by providing support for bytecode in sessions. Up until this time, sessions could only
  +support script-based requests, so that makes another added feature related to this one.
  +
  +IMPORTANT: The `g.tx()` is only supported in Java at this time. Support for other languages will come available in
  +future releases on the 3.5.x line.
  +
  +See: link:https://issues.apache.org/jira/browse/TINKERPOP-2537[TINKERPOP-2537],
  +link:https://tinkerpop.apache.org/docs/current/reference/#transactions[Reference Documentation - Transactions]
  +
   ==== Anonymous Child Traversals
   
   TinkerPop conventions for child traversals is to spawn them anonymously from `__`, therefore:
  
positive.code: 
  See: link:https://issues.apache.org/jira/browse/TINKERPOP-2481[TINKERPOP-2481],
  link:https://issues.apache.org/jira/browse/TINKERPOP-2499[TINKERPOP-2499]
  
  ==== Deprecation Removal
  
  
negative.code: link:https://issues.apache.org/jira/browse/TINKERPOP-2452[TINKERPOP-2452],
  link:https://issues.apache.org/jira/browse/TINKERPOP-2527[TINKERPOP-2527]
  
  ==== Versions and Dependencies
  
  *Apache Commons*
  
  