0
votes

What are pros and cons of implementing a custom scope vs using a dedicated child container for an independent job execution?

I'm implementing a complex business functionality that needs a couple of dedicated beans. So far I managed fine to create objects with custom factories or object providers in prototype scope per execution and keep others stateless as singleton beans, but as complexity rises, I want to get a better container support for my job executions.

I did a project some time ago, where I implemented a custom scope. We used a thread scope that's inherited by child threads, so we only needed to ensure that the job was executed in it's own thread graph.

My last project used spring batch for batch job execution. In the spring batch docs I read the recommendation to use a child container per job, once thing's are starting to get complex. Additionally, it provides JobScope and StepScope.

I would be really interested in performance statistics and complexity experience?

Currently, I'm leaning to a child container and would include spring batch dependency for the ContainerFactory. I assume, it caches the annotation meta data, so it's not costly on every creation. In general, the project isn't fit for spring batch, so I'd prefer to pull that little dependency out somewhere down the road.Goatfryed
I would use a separate application context containing infrastructure beans (job repository, job launcher, etc) and a single job definition (along with it steps, reader, writer, etc) and package each job in its own jar.Mahmoud Ben Hassine