2015-10-09 2 views
3

Я использую весеннюю партию HibernateCursorItemReader, он определяется следующим образомHibernateCursorItemReader Результат набор уже закрыт

<bean class="org.springframework.batch.item.database.HibernateCursorItemReader" 
     scope="step" id="priceListFctrItemReader"> 
    <property name="queryName" value="FIND_ALL_PRICE_LIST_FCTR_ITEM_ID_BY_MONTRY_FCTR_VER"/> 
    <property name="sessionFactory" ref="sessionFactory"/> 
    <property name="parameterValues"> 
     <map> 
      <entry key="factorVersion" value="#{jobParameters['current.factor.version']}"/> 
      <entry key="trueValue" value="#{true}"/> 
     </map> 
    </property> 
</bean> 

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

org.hibernate.exception.GenericJDBCException: could not advance using next() 
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54) 
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) 
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) 

и далее вниз

Caused by: java.sql.SQLException: Result set already closed 
at weblogic.jdbc.wrapper.ResultSet.checkResultSet(ResultSet.java:144) 
at weblogic.jdbc.wrapper.ResultSet.preInvocationHandler(ResultSet.java:93) 

Я не испытать это в весенне-ботинке, но на WebLogic я. Может быть, местный весенний ботинок только быстрее.

любые идеи о том, как этого избежать?

+0

Я так пробовал JdbcCursorItemReader с теми же результатами. Как только он пытается переместить курсор, результирующий набор закрывается, и он терпит неудачу. Даже с фиксированным интервалом в 1. Я подозреваю, что набор результатов закрывается при записи шага. Я попытался установить useSharedExtendedConnection в true с источником данных, который поддерживает это. не повезло. Я работаю на weblogic, я думаю, что проблема с weblogic может быть проблемой –

ответ

2

Проблема в том, что spring-batch выполняет фиксацию после каждого куска, а фиксация завершает транзакцию и, следовательно, результат.

Если вы не используете контейнер приложений, например, когда вы используете весеннюю загрузку, * CursorItemReaders используют отдельное соединение для обхода транзакции и тем самым избегают фиксации, которая закрывает набор результатов курсора.

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

В качестве альтернативы, вы можете быть в состоянии использовать * PagingItemReader, который считывает размер страницу записей в порции, каждая в отдельной транзакции. Это полностью исключает проблему закрытия набора результатов. Остерегайтесь: Если базовая таблица изменяется между кусками, результаты могут быть не такими, какие вы ожидаете!


[а]: https://blog.codecentric.de/en/2012/03/transactions-in-spring-batch-part-2-restart-cursor-based-reading-and-listeners/

+0

http://blog.bsg.co.za/2015/11/10/spring-batch-item-readers.html –

Смежные вопросы