[wildfly-dev] Batch Subsystem Model

James R. Perkins jperkins at redhat.com
Fri Sep 13 11:17:18 EDT 2013


Thanks for all the feedback. If I'm understanding everything right we'll 
end with something like the following for in-memory.

<subsystem xmlns="urn:jboss:domain:batch:1.0">
     <job-repository>
         <in-memory thread-pool="default"/>
     </job-repository>
     <thread-pool name="default">
         <max-threads count="10"/>
         <keepalive-time time="100" unit="milliseconds"/>
     </thread-pool>
</subsystem>

"subsystem" => {
     "batch" => {
         "job-repository" => { "in-memory" => {
             "thread-pool" => "default"
         }},
         "thread-pool" => { "default" => {
             "max-threads" => "10",
             "keepalive-time" => "100",
             "keepalive-unit" => "milliseconds"
         }}
     }
}

And something like the following for JDBC.

<subsystem xmlns="urn:jboss:domain:batch:1.0">
     <job-repository>
         <jdbc thread-pool="default" 
jndi-name="java:jboss/datasources/ExampleDS"/>
     </job-repository>
     <thread-pool name="default">
         <max-threads count="10"/>
         <keepalive-time time="100" unit="milliseconds"/>
     </thread-pool>
</subsystem>

"subsystem" => {
     "batch" => {
         "job-repository" => { "jdbc" => {
             "thread-pool" => "default",
             "jndi-name" => "java:jboss/datasources/ExampleDS"
         }},
         "thread-pool" => { "default" => {
             "max-threads" => "10",
             "keepalive-time" => "100",
             "keepalive-unit" => "milliseconds"
         }}
     }
}

I personally prefer the <job-repository><in-memory/></job-repository> 
over the <in-memory-job-repository/>, but I don't care all that much. If 
the consensus is the later, that's fine.

Also do we want the thread pool to be called batch-thread-pool or just 
simply thread-pool?

Thanks for all the feedback. I just wanted to get it right since what we 
decide we're stuck with.

-- 
James R. Perkins
Red Hat JBoss Middleware



More information about the wildfly-dev mailing list