JBeret / JSR352 - Should JdbcItemReader be used with jberet.local-tx?

[xkylex]

In my understanding, each open, read, write and close of every JDBC resources (Connection, Statement and ResultSet) needs to be in it's own transaction. however, JdbcItemReader opens Connection, Statement and ResultSet in ItemReader#open(), then closes every resources in ItemReader#close(). it uses these resources across multiple transaction.

https://github.com/jberet/jsr352/blob/master/jberet-support/src/main/java/org/jberet/support/io/JdbcItemReader.java

According to following discussion, it seems like violates the spec of JCA or something and encouraged to use "jberet.local-tx" to handle transactions manually as a workaround for a while.

https://developer.jboss.org/message/863072

https://issues.jboss.org/browse/WFLY-3135

Also I checked a documentation of JdbcItemReader but there's no mention of jberet.local-tx or the problem about handling of JDBC resources across multiple transaction.

https://github.com/jberet/jberet-user-guide/tree/master/read_and_write_data_through_jdbc

So should I JdbcItemReader use with jberet.local-tx? or am I misunderstood something?

Thanks.

[jamezp]

As I understand the issue the batch spec wants to do a lot of transactions. With JCA a JDBC resource is enlisted in the transaction when it's open and unenlisted when it's committed. Since batch commits the chunk after each open, read and write the JDBC needs to be opened in the read. What the jberet.local-tx=true property does is just uses a local transactions for the open, read and write. It's up to the ItemReader to determine when to commit the transaction.

The timing on this question is good though. I'm going to be meeting with the JCA team next week and see if we can figure out a better way to deal with this. I'm not too familiar with the JdbcItemReader, but at first glance it does appear the issue would show up if you were to use it.

I'm not sure if I actually answered your question or not Hopefully in a couple weeks I'll have a better answer and hopefully a better understanding.

--

James R. Perkins

[xkylex]

As to the spec I have completely same understanding as you.

Also I'm curious why "ARJUNA016087: TransactionImple.delistResource - unknown resource" disappeared on WildFly 8.2.0.Final running the example app (https://www.dropbox.com/s/rl95nlmp4pu71c7/batch-test.zip). I can see ARJUNA016087 when I deploy it on WildFly 8.1.0.CR1. I suspect that is it made by chance or intended to fix the issue.

I'd appreciate if you give me some feedback about the issue after the meeting.

Note: I used following command to define xa-data-source.

xa-data-source add \

--name=IssuerXADS \

--driver-name=h2 \

--jndi-name=java:/ISSUER_DS \

--user-name=sa \

--password=sa \

--xa-datasource-properties={ \

  "URL" => "jdbc:h2:mem:batchtest"}

Also I changed SQL grammar of File0591Reader.java to make it runnable on H2.

statement.execute("select '" + value + "' as value");

Thanks.

[jamezp]

After talking with the transaction team it was determined the best solution would be to use a non-transactional data source for reads. It's likely not needed for reads anyway.

--

James R. Perkins

[xkylex]

OK, I'd go with jberet.local-tx until the update of the JSR352 spec. thanks!

[xkylex]

I guess I misunderstood that. we can simply use different datasource between ItemReader (jta=false) and ItemWriter as follows. in such case we don't need jberet.local-tx anymore. lbtc-xxx/jberet-support-jdbc-example · GitHub

[jamezp]

I think I led the misunderstanding as I was misunderstanding the issue as well But yes using a non-JTA data source for reads is the best option.

--

James R. Perkins