blocks|key|80338|text|每个作业由三个步骤组成，即读取步骤、过程步骤和写入步骤。如果您创建了一个具有步骤作用域的bean，那么您可以从这三个步骤中的每一个步骤引用它--但是在每个步骤中都会得到该bean的不同实例。我创建了一个带有作业范围的bean，然后您可以从这三个步骤中的每一个引用它--在这三个上下文中它都是相同的实例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|80339|因此，如果需要在bean中存储一个步骤，而同一作业中的后续步骤将访问它，则希望该bean位于作业范围内。如果希望保证任何步骤在bean中存储和操作的数据都是该步骤的本地数据(对其他步骤隐藏)，则希望该bean处于逐步范围内。|80340|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Each job is composed of three steps, a read step, a process step, and a write step. If you create a bean with Step scope, then you could reference it from each of these three steps - but you would get a different instance of that bean in each step. I you create a bean with Job scope, then you could reference it from each of these three steps - and it would be the same instance in all three contexts.

So, if you need to have one step store something in a bean that a later step in the same job will access, you want that bean to be in Job scope. If you want to guarantee that the data that any step stores and manipulates in your bean is local to that step (hidden from the others), then you want that bean to be in Step scope.

blocks|key|526829|text|步骤由读取、转换/进程和写入阶段组成，后者是每个块在处理阶段都会出现复杂的重试/回滚过程，而读取阶段通常是不回滚不重试。一个任务是由任意多个步骤组成的，每个步骤都是你喜欢的。因此，步骤作用域bean对于每个读/进程/写阶段和给定步骤的侦听器都是相同的实例。作业范围是作业中所有步骤的相同实例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|526830|因此，如果您需要在一个作业的多个步骤中使用同一个侦听器进行某些处理(您有一个步骤将数据转换为中间格式并进行验证，然后一个步骤将所有数据处理到您的数据库，并且您希望同一个侦听器在某个地方执行一些异步审核过程)，那么您将作业范围这个侦听器并根据作业中的两个步骤注册它。这样，每一步都会看到代理后面的对象的相同实例，在同一个实例上的相同方法将被调用用于诸如"on+read+error“或"after+way”或"after+step“(取决于您是使用基于注释的侦听器还是基于接口的侦听器，以及您正在侦听的内容)。|526831|例如，您的读取器在任何时候都只能用一个步骤来使用，因此将像您的读取器这样的内容作为步骤作用域通常是正确的，在这里创建阅读器并指向特定的资源。一个更好的示例是侦听器，您可能需要在步骤完成后清理目录或执行某些操作，但由于此过程随每个步骤更改(目录位置)，尽管您希望侦听器具有相同的实际对象类型，而且您甚至希望它执行相同的操作，您甚至希望它使用一个新目录和一个新的UUID前缀，或者每一步使用一些内容，您将为该bean提供一个定义，可能使用相同的作业参数，但该定义将新增加一个临时目录或UUID等，并将该bean定义设置为步骤范围，这样当您将其连接到两个不同的步骤时，它们就会在延迟代理后面得到两个不同的实际对象。|526832|现在，作业侦听器可能应该是作业作用域，但这里提出了一个问题，如果您希望在所有步骤(和+all作业)上使用相同的实例，那么您可以使用“常规作用域”单例，然后使用它。|offset|length|style|BOLD|526833|在作业之外，您不能看到作业范围或步骤范围。|unordered-list-item|526834|在步骤之外，您看不到步骤范围。|526835|或|526836|在步骤内部，您可以看到作业和步骤范围bean。|526837|在作业内部，您可以看到所有的作业范围bean或单件|526838|还应考虑：|526839|当您创建一个单例，并且它有一个作业范围或步骤作用域bean，即使您的单例对象是“处处”使用的相同对象，当它引用任务或步骤范围内的对象(实际上是一个代理)时，它将相应地看到每个作业或步骤中的不同对象。因此，您可以有一个表示步骤的单例bean，该步骤可以引用步骤范围内的bean。这样，您使用Step构建Job的实例就应该是单独的，但它已经连接到它的bean方法/定义/构造函数中，它在执行时所依赖的步长范围bean是不同的实例。|CODE|526840|entityMap^0|0|0|0|15|1|0|0|0|0|0|0|0|40|4|46|3|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|16|8|@$H|17|I|18|J|K]]|9|@]|A|$]]|$1|L|3|M|5|N|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|N|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1F|8|@$H|1G|I|1H|J|10]|$H|1I|I|1J|J|10]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|12|$]]

A step is composed of a read, transform/process, and write stage, the latter is per chunk with retry / rollback complications through the process stage, and the read stage is usually no-rollback no-retry. A Job is composed of as many steps, each doing that, as you like. So a step scope bean is the same instance for each read/process/write phase and listeners of a given step. Job scope is the same instance for all steps in a job.

So, if you need to use the same listener for some processing in multiple steps of a job (you have a step to convert data to an intermediary format and validate, then a step to process all data to your database and you want the same listener to do some async auditing process somewhere) then you would job scope that listener and register it against both steps in the job. This way, each step would see the same instance of the object behind the proxy and the same methods on the same instance would be called for things like "on read error" or "after write" or "after step" (depending if you're using annotation based listener or interface based listener and what you're listening for)

Your reader, for example, is / should only be used by one step at any time, so having things like your readers as step scope is usually correct, where that reader is created and pointed at a particular resource. A better example is a listener that you need to perhaps clean up a directory or do something after a step has completed, but because this process changes (location of directory) with each step, although you want the same actual object type for the listener, and you might even want it to do the same thing, you want it to use a new directory and a new UUID prefix or something per step, you'd have one definition for that bean perhaps using the same Job parameters but the definition would new up a temp directory or UUID etc and you'd set that bean definition to Step scope so that when you wire it into two different steps they get two different actual objects behind the lazy proxies.

Now, a Job Listener should probably be job scoped, but here raises the question, if you want the same instance across all steps and all jobs, then you use a "regular scoped" singleton and use that instead.

<ul>
<li>Outside of a job you cannot see job scope or step scope</li>
<li>Outside of a step you cannot see step scope</li>
</ul>

Or

<ul>
<li>Inside of a step you can see job and step scope beans</li>
<li>Inside of a job you can see all Job scope beans or singletons</li>
</ul>

Also To Consider:

When you create a singleton and it has, wired into it, a job scope or step scope bean, even though your singleton is the same object used "everywhere" , when it references the job or step scoped object inside (really a proxy) it will see a different one per job or step accordingly.
So you can have a singleton bean that represents your step and the step can reference step scoped beans. That way your <code>Step</code> instance you build your <code>Job</code> with could and possibly should just be a singleton but it has wired into it's bean method / definition / constructor the step scoped beans it relies upon at execution to be different instances.

I'm working on a project using Spring Batch. In this project, I use Spring Batch late binding in which I injected a parameter (a string that will be used as a condition for SQL reader query) using JobParameters. Currently, I'm using the <code>@StepScope</code> for that late binding and everything works perfectly fine.

What I'm asking here is when to use <code>@StepScope</code> and when to use <code>@JobScope</code>. I've read the Spring Batch reference and I've googled about StepScope and JobScope. All I'm getting is that :

a. StepScope : Spring Batch will use the spring container to instantiate a new instance of that component for each step execution.

b. JobScope : There will be only one instance per executing job.

I just can't determine the consideration of when to use StepScope or JobScope. Can someone explain a little deeper?

Spring Batch Late Binding - Step Scope or Job Scope?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在使用Spring进行一个项目。在这个项目中，我使用Spring批处理后期绑定，在这个绑定中，我使用JobParameters.注入了一个参数(一个字符串将用作SQL查询的条件)目前，我正在使用@StepScope进行后期绑定，而且一切都很好。这里我要问的是什么时候使用@StepScope，什么时候使用@JobSc...

问春季批后期绑定-步骤范围还是作业范围？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问春季批后期绑定-步骤范围还是作业范围？EN