事务深度遍历过程详解

事务

创建事务：

想显式地回滚一个事务，例如从一个条件代码块，可以调用failure方法，则事务将在程序块的结束做无条件的回滚。既不调用success方法也不调用failure方法也将会导致事务回滚（默认）。

在一个事务中定义USER标签的name作为模式可索引的属性，然后使用分离的事务实际设置一个真实用户的值：

许多数据库管理系统使用锁机制来管理对同一个数据库的同时访问。Neo4j 事务是由清晰的读锁和写锁来控制每一个图形数据库资源（节点和关系）。

多个读锁之间并不相互排斥，在同一时间的多线程中，可以在同一数据资源中获得多个读锁。在给定的时刻，对同一数据资源只能获得一个写锁，还必须没有其他激活的锁，不管是读锁还是写锁。

Neo4j事务的默认设置并不自动获取读锁。因此，读的数据是节点、关系、索引实体最新提交的状态，除非在它自己的事务中，局域的修改（即使没提交）是可见的。

写锁则是在对任意图形资源试图做变更操作时自动获得，在事务的持续时 间内都有效。每一个事务确保在完成时自动释放所有的锁。

如果需要一个更高级别的隔离以确保其他人不能修改正在读的图形资源， Neo4j提供了一个潜在的显式获取对图形资源的读锁。程序7-5给出了相应 代码，但是这一次在读取任何的属性之前有一个额外的显式请求获取对节点的读锁。

当读数据时，有两个很好的理由避免使用系统的锁。就像以前提及的，首先这将产生事务的状态，并且很占内存。第二，这里主要的权衡是同时写数据，因为线程希望更新任何有显式读锁的节点或关系，在锁被释放或事务完成前是锁定的。

如果事务A试图按节点1和节点2的顺序锁定它们，而事务B试图对相同的节点按相反的顺序获取锁，那么每一个事务可能会锁定一个节点并且无限期地等待另一个节点释放，从而产生一个无效锁。

当无效锁发生的时候，Neo4j具有一个内置的机制对其进行探测，若有，则 抛出一个DeadlockDetectedException异常并且事务回滚。当锁定是由Neo4j专门管理时，才能进行无效锁的探测，这意味着通过依赖于Neo4j的自动默认锁定机制，或者仅仅通过使用我们前面讨论过的Neo4j API的相关锁定方法（acquireReadLock和acquireWriteLock）。如果使用任何其他的锁定机制，例如使用Java的同步（synchronized）关键词，即使发生 无效锁也不会被探测出，应用程序很有可能出现终止。

要有效处理无效锁：第一个坚持使用Neo4j提供的核心API而不使用任何外部的锁定机制。这将确保Neo4j的无效锁探测机制是有效的，确保你的应用程序不会完全锁死，并且数据会保持一致性。在Neo4j核心API中的所有操作（除非另有指定）都是线程安全的，因此，一般不需要外部的同步。另一个是通过确保图形资源能够以同样的顺序进行访问来避免无效锁。

深度遍历

① 遍历的顺序

每一次遍历器访问一个节点，它都需要决定下一步沿着哪个关系访问哪个节点，重复这个过程直至遍历结束。通过在图形中选择一个合适的路径，遍历可以很快结束并且使用很少内存。这是图论中的两个主要顺序算法，并且这两个算法用于大多数的Neo4j遍历中：深度优先（depth-first）算法和广度优先（breadth-first）算法。

深度优先：

深度优先顺序表明你应该首先跳到现在所在且以前没有访问过的节点的第一级子 节点。如果所有的下一代子节点都已经访问过，就应该返回具有没有访问过的子节点的第一个节点上。

使用Neo4j遍历API深度优先遍历整个图形：

深度优先是Neo4j默认的分支顺序策略。当建立遍历描述时，如果不指定遍历的顺序，则默认为深度优先。