Spring Batch 带有非常旧的 JDBC 1.0 驱动程序
我正在处理一个困难的企业集成场景，涉及过时的IEX TotalView (3.12.6.0.8)。 ODBC 驱动程序仅适用于 32 位体系结构 - 好吧，无论如何我都在使用 Java。但基于 Simba RPC 的 JDBC 驱动程序仅兼容 JDBC 1.0，并且在许多方面受到限制，我没有完整记录这些限制（一个缺陷是它似乎不支持准备好的语句，至少不是很好）。
我正在尝试使用 Spring Batch 和 Apache Camel 构建一座桥梁，用于从中提取 WFM 数据IEX，但我在路上遇到了很多坎坷。例如， JdbcCursorItemReader 失败下：
preparedStatement = con.prepareStatement(
sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
...带有java.sql.SQLException：驱动程序不支持。我已经使用 JdbcTemplate 带有 RowMapper，但是这种组合让我要么自己驱动提取（违背了 Spring Batch 的目的），要么将整个结果集加载到列表中（违背了分页/流的目的）。
现在我正在尝试使用 JdbcPagingItemReader 通过扩展 AbstractSqlPagingQueryProvider< /a> 实现我自己的基于查询的 分页策略，但事实证明它比预期的更困难。
我是 Spring Batch 的新手，所以我可能会忽略一些东西。还有其他人有任何利用 Spring 与旧的/有缺陷的/有缺陷的 JDBC 驱动程序的策略吗？
I'm working a difficult enterprise integration scenario involving an antiquated version of IEX TotalView (3.12.6.0.8). The ODBC driver only works on 32-bit architectures - fine, I'm using Java anyway. But the Simba RPC-based JDBC driver is only JDBC 1.0 compliant and is limited in many ways that I don't have fully documented (one deficiency is that it appears to not support prepared statements, at least not very well).
I'm trying to use Spring Batch and Apache Camel to build a bridge for extracting WFM data from IEX, but I'm hitting a lot of bumps in the road. For example, JdbcCursorItemReader fails under:
preparedStatement = con.prepareStatement(
sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
… with java.sql.SQLException: Driver Not Capable. I've gotten by in simpler ETL scenarios using JdbcTemplate with a RowMapper, but this combination leaves me either driving the extraction myself (defeating the purpose of Spring Batch), or else loading the entire result set into a List (defeating the purpose of paging/streaming).
Right now I'm trying to use a JdbcPagingItemReader by extending AbstractSqlPagingQueryProvider to implement my own query-based paging strategy, but it's proving more difficult than anticipated.
I'm new to Spring Batch, so I could be overlooking something. Does anyone else have any strategies for leveraging Spring with old/deficient/defective JDBC drivers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
现在，我决定发展自己的
ItemReaderbean 天真地查询其DataSource通过 JDBC API 属性。不是那么优雅，但没有什么可以（或应该）无限期地向后兼容。只要我记得好好清理，这应该会很顺利。For now, I decided to grow my own
ItemReaderbean that naïvely queries itsDataSourceproperty via the JDBC API. Not as elegant, but nothing can (or should) be indefinitely backwards-compatible. As long as I remember to clean up nicely, this should work out fine.