Data truncation: Data too long for column 'SERIALIZED_CONTEXT' at row 1

[geeky2]

hello,

i am new to SB and tracking down an issue we are seeing when running in production that did not manifest itself during QA.

can someone help me understand the issue here and how to correct it?

we used the standard create scripts to create the persistent job repository.

Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'SERIALIZED_CONTEXT' at row 1
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.ja va:2932)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:16 16)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java :1708)
at com.mysql.jdbc.Connection.execSQL(Connection.java: 3255)
at com.mysql.jdbc.PreparedStatement.executeInternal(P reparedStatement.java:1293)
at com.mysql.jdbc.PreparedStatement.executeUpdate(Pre paredStatement.java:1566)
at com.mysql.jdbc.PreparedStatement.executeUpdate(Pre paredStatement.java:1480)
at com.mysql.jdbc.PreparedStatement.executeUpdate(Pre paredStatement.java:1465)
at org.apache.commons.dbcp.DelegatingPreparedStatemen t.executeUpdate(DelegatingPreparedStatement.java:9 4)
at org.springframework.jdbc.core.JdbcTemplate$2.doInP reparedStatement(JdbcTemplate.java:818)
at org.springframework.jdbc.core.JdbcTemplate$2.doInP reparedStatement(JdbcTemplate.java:1)
at org.springframework.jdbc.core.JdbcTemplate.execute (JdbcTemplate.java:587)
... 29 more

[mminella]

In the scripts provided with the framework, we create the SERIALIZED_CONTEXT column to be a TEXT column in MySQL which limits the size to about 65kb. Unless you're putting in a large amount of data, this should be ok. However, if you are putting in large amounts of data:

1. Does all of that data need to be shared via the ExecutionContext?
2. In Spring Batch 2.2.0 we'll be allowing you to inject alternative serializers to choose other options.
3. Increase the size of both SERIALIZED_CONTEXT columns (one on the BATCH_JOB_EXECUTION_CONTEXT and one on the BATCH_STEP_EXECUTION_CONTEXT).

[rizwanbpatel]

If the data is not needed and can be pulled again so why need to store as part of the ExecutionContext?
Instead you can have the flag value store for the availability of data and read in the next step or wherever required.