Question

我通过Alex Smirnov neo4j JCA连接器的修改版本在glassfish服务器中使用neo4j。我的版本可在此处找到：https://github.com/Riduidel/neo4j-connector 我正在使用neo4j 1.8的这个连接器。因此，当我想使用它时，我首先在我的Glassfish应用程序服务器中安装连接器，然后在希望连接的应用程序中使用此连接器。

在新鲜商店使用时效果很好。但是，当它与以前版本创建的商店一起使用时，我遇到了奇怪的错误。

通常，我今天得到了以下堆栈

javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@3bbd53b1 from NONE to STOPPED
...
...
.../* JCA internal exception stack */
...
...
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@494b584c from NONE to STOPPED
 at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
 at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1185)
 at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
 ... 66 more
Caused by: org.neo4j.kernel.lifecycle.LifecycleException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@494b584c from NONE to STOPPED
 at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:388)
 at org.neo4j.kernel.lifecycle.LifeSupport.init(LifeSupport.java:82)
 at org.neo4j.kernel.lifecycle.LifeSupport.start(LifeSupport.java:116)
 at org.neo4j.kernel.InternalAbstractGraphDatabase.run(InternalAbstractGraphDatabase.java:227)
 at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:79)
 at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:70)
 at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:165)
 at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:127)
 at com.netoprise.neo4j.Neo4jManagedConnectionFactory.createManagedConnection(Neo4jManagedConnectionFactory.java:163)
 at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:160)
 at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
 ... 68 more
Caused by: java.lang.AssertionError
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:265)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.<init>(LuceneDataSource.java:185)
 at org.neo4j.index.lucene.LuceneIndexProvider.load(LuceneIndexProvider.java:72)
 at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.loadIndexImplementations(InternalAbstractGraphDatabase.java:1171)
 at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.init(InternalAbstractGraphDatabase.java:1143)
 at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:382)
 ... 78 more

快速检查显示此异常与不可删除的“write.lock”文件相关联。我的write.lock文件无法删除，因为我猜迁移还没有结束。如何在使用之前确保迁移完成而不将其迁移到Glassfish之外？

有没有办法在该上下文中进行独家商店迁移？如果是这样，怎么样？它是我问题的解决方案吗？

编辑1 添加了异常消息。

编辑2 所有这一切只发生在以前加载的图形与Neo4j 1.5和Neo4j 1.8连接器一起使用时。当图形由连接器创建时，绝对不会发生错误。

编辑3 奇怪的是，只要没有调试器插入该代码就会发生这种情况：只要我尝试调试它，问题就会停止显示。这让我觉得可能有一个迁移清理机制，一旦完成迁移就会撤消写锁定，并且在使用我的neo4j JCA连接器时不会执行此清理。这是一个有效的观察吗？

Answer 1

我对JCA连接器不太熟悉，但可以肯定的是，我只会编写一个非常小的迁移java类来打开数据库，让它迁移和关闭。然后使用JCA连接器再次尝试？

Answer 2

经过进一步调查后，事实显示不是多次调用EmbeddedGraphDatabase构造函数，而是加载了多个identicail IndexProvider。

我使用嵌入在开源JCA连接器中的neo4j。在此连接器中，org.neo4j.kernel.Service类由a custom one替换，其中包含有关JBoss非共享库的服务加载的解决方法。遗憾的是，在我们的上下文中，此解决方法意味着加载两倍的索引提供程序：

一次使用EAR类加载器
一次使用Glassfish库类加载器。

为什么？因为，当我们的neo4j实例用于应用程序数据AND进行身份验证时，neo4j连接器jar放在${domain}/lib中。因此，由于应用程序服务器中的类加载器委派，EAR类加载器委托给Glassfish库类加载器，并以LuceneIndexProvider的方式查找。然后，Glassfish库类加载器直接用于加载相同的LuceneIndexProvider类。

我们总结了两个LuceneIndexProvider对象，两者都试图迁移lucene索引。导致AssertionError作为第一个对象创建的write.lock文件的应该被第二个删除，但是不能这样做。

然后我稍微改变了一个非常具体的类，只有当默认加载机制没有返回任何类（seee commit here）时才使用JBoss解决方法。这个微小的变化就像一个魅力，所以我认为你可以认为这个问题是固定的。

当allow_store_upgrade失败时，我该怎么办？

2 个答案: