0

I have some code that used to run with bean managed transactions (my code would handle when to start or commit a transaction). This code was migrated to a container managed transaction and finally is used from within Java Batch (JSR-352 within Wildfly).

Now that the amount of data we process grows we see transaction-related problems. In various cases even a query fails, and the exception indicates the transaction is marked for rollback-only. So I assume some error must have happened during the migrations before.

I still want to go with container managed transactions, but...

  • how do I correctly use CDI in a batchlet so it receives an EntityManager? Do I use @PersistenceContext, @PersistenceUnit or @Inject annotations, or a combination?
  • how do I make use of a reasonable CDI scope? Looking at https://github.com/jberet/jberet-user-guide/blob/master/custom_cdi_scopes/README.md it occurs there are three scopes: Job, Step and Partition. As the batchlet I have runs for too long I probably need partition-scoped but how would the batchlet then control partitions?
  • I learned that reader/processor/writer pattern controls transactions ootb for chunk-amounts of records. Is that pattern applicable for code that reads a record, processes it and then immediately updates or deletes it?
Queeg
  • 7,748
  • 1
  • 16
  • 42

2 Answers2

1

Meanwhile I found the issue, and similarly to me posting a vague question I can now see that the answer was not easily concluded to my question.

My code used to run without container, so obviously it managed it's transactions on it's own. Later a container was added, and eventually I started writing code that used container managed transactions. But there was only one persistence unit, and it got configured for container-managed transactions. This seemed to be no problem for a long time until the data set grew.

The solution was for me to have two persistence units - one with and one without container managed transations: One is resource-local, the other JTA. My code needs to use the correct persistence unit so that transactions get managed properly.

Queeg
  • 7,748
  • 1
  • 16
  • 42
  • That's right. The JPA specification has always done a poor job at making it obvious that there are two "modes": "application mode" JPA (where you call things like `Persistence#createEntityManagerFactory()` and manage your own transactions, and "container mode" JPA (where very specific transaction-related rules apply once you inject an `EntityManager` via `@PersistenceContext`). – Laird Nelson Mar 08 '21 at 03:42
0

You check out WildFly Quickstart for batch processing, which contains some useful examples of mixing batch, CDI and JPA, including injecting persistent context with @Inject.

For the use of various CDI scopes with JBeret, it depends on your specific use case. For most batch processing applicatins, they probably don't need to worry about it. But if you do find yourself need to control the scope of certain CDI beans, then choose the scope that fits the expected life cycle of the beans most.

If you want to immediately update it or delete it in your item writer, you can certaily choose item-count of 1. It's doable, but that will be less efficient.

cheng
  • 1,076
  • 6
  • 6
  • Thank you for the suggestion. This time the probem was not on JBatch at all as my batchlet controls the transaction well. However the persistence unit was configured for JTA which means the container also tried to control the transaction. – Queeg Mar 06 '21 at 23:42