LINUX.ORG.RU

про jpa и eclipseLink

 ,


0

1

есть у меня Entity, внутри которой лист Entity, внутьри которых тоже листы и там их штук 5 таких вложений.

и снаружи мне приходит пакет, который надо в этот ентити разобрать и заперсистить или смержить.

и все вроде хорошо, но если пакет большой, то эта радость рушится, любимых ошибки у меня две: elipseLink-4005 и eclipseLink-4002. 4005 в топе.

что бесит отдельно: тест не повторяется. один тест может 3 раза упасть, а на 4-ый отработать и в табличках записи появятся.

про обе ошибки гугл говорит что я их не должен видеть, магия особо не помогает.

вопрос: что делать? :)

trace:

Exception [EclipseLink-4005] (Eclipse Persistence Services - 2.6.4.v20160829-44060b6): org.eclipse.persistence.exceptions.DatabaseException
Exception Description: DatabaseAccessor not connected.
	at org.eclipse.persistence.exceptions.DatabaseException.databaseAccessorNotConnected(DatabaseException.java:123)
	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:325)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:615)
	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:560)
	at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:2056)
	at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
	at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:258)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
	at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
	at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2740)
	at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRows(ExpressionQueryMechanism.java:2693)
	at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:559)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1175)
	at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:904)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1134)
	at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:460)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1222)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2896)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1857)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1839)
	at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:133)
	at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:120)
	at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:89)
	at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:173)
	at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:234)
	at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:89)
	at org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:271)
	at org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:455)
	at org.eclipse.persistence.indirection.IndirectList.getDelegateObject(IndirectList.java:469)
	at org.eclipse.persistence.internal.sessions.DeferrableChangeRecord.recreateOriginalCollection(DeferrableChangeRecord.java:120)
	at org.eclipse.persistence.mappings.CollectionMapping.updateChangeRecord(CollectionMapping.java:2124)
	at org.eclipse.persistence.internal.descriptors.changetracking.AttributeChangeListener.internalPropertyChange(AttributeChangeListener.java:149)
	at org.eclipse.persistence.internal.descriptors.changetracking.AttributeChangeListener.propertyChange(AttributeChangeListener.java:111)
	at ru.its360.core.prototype.entity.Reference._persistence_propertyChange(Reference.java)
	at ru.tabulaRasa.buildingApi.entity.BuildingStruct._persistence_set_sections(BuildingStruct.java)

Ответ на: комментарий от Rastafarra

тады вдумчиво кури ошибку и что пишут. а пишут что возможно кончаются коннекты, копай так ли это

Deleted
()
Ответ на: комментарий от Deleted

возможно кончаются коннекты, копай так ли это

поднял их уже 400, думаешь прибавить? :)

смотрел, вроде как ей хватает.

Rastafarra ★★★★
() автор топика
Последнее исправление: Rastafarra (всего исправлений: 1)
Ответ на: комментарий от Rastafarra

думаешь прибавить? :)

думаю надо ловить запрос который все ложить, брать отладчик в руки и диагностировать, а не заниматься херней

Deleted
()
Ответ на: комментарий от bvn13

у нее есть persist.xml, где этот пул и настраивается. у меня минимум 100 коннектов, максимум 400, а постгресе, в котором это все лежит, 1200.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Deleted

надо ловить запрос который все ложить, брать отладчик в руки и диагностировать, а не заниматься херней

так и делается, я могу проиграть запрос, который не прошел, в любой момент, я их складирую отдельно.

но.

что бесит отдельно: тест не повторяется. один тест может 3 раза упасть, а на 4-ый отработать и в табличках записи появятся.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Deleted

увы и ах, под дебагером все ваще отлично работает, а что именно добавить в логи для отладки я уже и не знаю.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

что именно добавить в логи для отладки я уже и не знаю.

1) в том месте где возникает ошибка снять дамп потоков (это надо или подсовывать патченный класс или инструментировать, были дето утилиты даже)

2) логировать открытие - закрытие коннекшена. Когда ошибка случилась смотреть сколько коннекшенов было открыто, если много то см п.1, если мало то возможно база разорвала соединение и надо курить что там в логах

Если в дебаггере с одним брекпоинтом на DatabaseException.java:123 оно не падает, то все это пахнет ошибками многопоточности. Но тогда оно бы не падало на однопоточных текстах. Еще вариант - idea (или в чем ты там) при отладке подпихивает всякой херни в класспас, потому можно запустить приложение отдельно и подцепиться отладчиком через сокет, а там пробовать поймать ошибку.

Deleted
()
Ответ на: комментарий от vertexua

ты прямо кла́дешь информации

Deleted
()

Кажется, с jpa всегда так. Вроде вот оно, быстро и легко работается, никаких ручных запросов, легко добавлять и менять энтити и тесты. Но периодически вылезает косяк, с которым приходится ну очень долго разбираться, копаться в исходниках поставщика реализации, жонглировать версиями и опциями, да и вообще весело проводить время.

orm-i-auga ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.