Что мне делать, если allow_store_upgrade не удается?

Question

Я использую neo4j в сервере Glassfish через модифицированную версию разъема JCA от Alex Smirnov 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 

Быстрый осмотр показывает, что это исключение связано с Undeletable файла «write.lock». Мой файл write.lock не может быть удален, потому что Я думаю, Миграция еще не окончена. Как я могу убедиться, что миграция выполнена до ее использования, не перенося ее за пределы Glassfish?

Есть ли способ для эксклюзивных миграций магазина ahve в этом контексте? И если да, то как? И это решение для моей проблемы?

EDIT 1 Добавлено сообщение об исключении.

EDIT 2 Все это происходит только тогда, когда ранее загруженный график использовался с Neo4j 1.5 и теперь с разъемом Neo4j 1.8. когда граф создается коннектором, абсолютно никакой ошибки не происходит.

EDIT 3 Как ни странно, это происходит до тех пор, пока в этот код нет отладчика: как только я попытаюсь его отладить, проблема перестанет появляться. Что заставляет меня думать, что может быть механизм очистки миграции, который блокирует блокировку записи после завершения миграции, и эта очистка не выполняется при использовании моего разъема JCA neo4j. Действительно ли это наблюдение?

Answer 1

После дальнейших расследований истина показала, что она не была в нескольких вызовах конструктора EmbeddedGraphDatabase, а вместо этого была загружена несколько идентификаторов IndexProvider.

Я использую neo4j, встроенный в разъем JCA с открытым исходным кодом. В этом разъеме класс org.neo4j.kernel.Service заменен на a custom one, который содержит обходное решение относительно загрузки сервисов для не разделяемых библиотек JBoss. Unfortunatly, в нашем контексте, это временное решение подразумевает загрузку дважды поставщика индекс:

1. раз используя EAR загрузчик классов
2. раз с использованием библиотеки загрузчика классов GlassFish.

Почему? Поскольку, как наш экземпляр neo4j использует данные приложения И для аутентификации, jon-разъем neo4j помещается в ${domain}/lib.Как следствие, из-за делегирования Classloader на сервере приложений, загрузчик классов EAR делегирует загрузчику классов Glassfish library и находит этот способ LuceneIndexProvider. Затем загрузчик классов Glassfish используется непосредственно для загрузки того же класса LuceneIndexProvider.

На этом мы заканчиваем работу с двумя объектами LuceneIndexProvider, которые пытаются перенести индекс lucene. Что приводит к AssertionError, так как файл write.lock, созданный первым объектом, должен быть удален вторым, что не может этого сделать.

Я немного изменил этот очень специфический класс, чтобы использовать обходной путь JBoss только тогда, когда механизм загрузки по умолчанию не возвращает какой-либо класс (seee commit here). Это небольшое изменение работало как шарм, поэтому я думаю, что вы можете считать эту проблему фиксированной.

Answer 2

Я не очень хорошо знаком с разъемом JCA, но, конечно, я бы написал очень маленький класс миграции java, который открывает базу данных, позволяет ей мигрировать и закрываться. Затем повторите попытку с помощью разъема JCA?