How is the Unit of Work used with batch processing?

Question

When building a web application, it is a standard practice to use one Unit of Work per HTTP request, and flush all the changes and commit the transaction once after handling the

Answer 1

The unit of work would be per request or shorter. (Lifetime scope) Longer-lived Contexts/Tx will lead to memory use and performance issues.

If it is a process that while a page is active the user is selecting records to be actioned on at a later stage in that session then I would consider tracking the selected IDs and applicable modifications client-side to be provided to the "act" step when triggered, or recording a simple batch record on the server session state or DB to associate the selected/modified entities. If stored in the DB there should be a date-time associated with the record and an automatic process to clean off any unprocessed batches that don't get finalized. (user abandons by closing browser for example.)

If it were a case of wanting to batch up records across many requests such as having web requests getting batched into groups of <=1000 or for a process to run every hour then I'd use a persistent data structure where the requests commit the data to the batch structure grouped by a batch run record which tracks the current state of the batch. 1. Check current batch status 2. If open, add/associate record to current batch. 3. If closed/processing, create new batch and associate record to new batch.

Interactions with the batch should be pessimistically locking so that the background process doesn't begin processing a batch while requests are being written.

The background batch process queries the batch to find the batch it should begin processing, update the status, process, and finalize the batch.