<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The EJB Specification, Concurrency, and Batch Processing</title>
	<atom:link href="http://javablog.franksalinas.net/2009/03/01/the-ejb-specification-concurrency-and-batch-processing/feed/" rel="self" type="application/rss+xml" />
	<link>http://javablog.franksalinas.net/2009/03/01/the-ejb-specification-concurrency-and-batch-processing/</link>
	<description>Java Enterprise Development &#38; Technology</description>
	<lastBuildDate>Wed, 10 Mar 2010 23:24:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Snehal Antani</title>
		<link>http://javablog.franksalinas.net/2009/03/01/the-ejb-specification-concurrency-and-batch-processing/comment-page-1/#comment-314</link>
		<dc:creator>Snehal Antani</dc:creator>
		<pubDate>Sun, 15 Nov 2009 18:39:45 +0000</pubDate>
		<guid isPermaLink="false">http://javablog.franksalinas.net/?p=211#comment-314</guid>
		<description>An interesting design point to consider is that the degree of parallelism should be a point-in-time decision, influenced by the available capacity of the system, service-level agreements (SLA&#039;s) of concurrent workloads (OLTP, Real-Time, etc), approaching deadlines for other batch jobs in execution, and so on. It&#039;s easy for a developer to arbitrarily spin off 10 commonj threads for parallel execution, but 10 threads may be too few or too many given the other workloads in the system. For designing parallel processing for batch, design the application to not care about the degree of parallelization. Shift the burden of assessing the degree of parallelization to the infrastructure, where some external component applies a partitioning algorithm to the job, dispatches the many instances of the job across the collection of application server threads, where each job instance operates on its own segment of the data. This is how we designed it in WebSphere Compute Grid, IBM&#039;s batch processing technology.

The following article and presentation discuss batch application design patterns. They are generally technology agnostic, though the examples are provided in the context of WebSphere Compute Grid.

- Batch application design:
- http://sites.google.com/site/snehalantani/designingBatchApps.zip
- http://sites.google.com/site/snehalantani/DesigningBatchApplications.pdf

Batch processing infrastructure overview: 
- http://sites.google.com/site/snehalantani/WebSphereDataIntensiveApps.pdf
- http://www-128.ibm.com/developerworks/websphere/techjournal/0804_antani/0804_antani.html

Customer experience with modern batch processing: 
- http://www-01.ibm.com/software/tivoli/features/ccr2/ccr2-2008-12/swissre-websphere-compute-grid-zos.html

Latest Compute Grid overview presentation: 
- http://sites.google.com/site/snehalantani/latestpresentationmaterial</description>
		<content:encoded><![CDATA[<p>An interesting design point to consider is that the degree of parallelism should be a point-in-time decision, influenced by the available capacity of the system, service-level agreements (SLA&#8217;s) of concurrent workloads (OLTP, Real-Time, etc), approaching deadlines for other batch jobs in execution, and so on. It&#8217;s easy for a developer to arbitrarily spin off 10 commonj threads for parallel execution, but 10 threads may be too few or too many given the other workloads in the system. For designing parallel processing for batch, design the application to not care about the degree of parallelization. Shift the burden of assessing the degree of parallelization to the infrastructure, where some external component applies a partitioning algorithm to the job, dispatches the many instances of the job across the collection of application server threads, where each job instance operates on its own segment of the data. This is how we designed it in WebSphere Compute Grid, IBM&#8217;s batch processing technology.</p>
<p>The following article and presentation discuss batch application design patterns. They are generally technology agnostic, though the examples are provided in the context of WebSphere Compute Grid.</p>
<p>- Batch application design:<br />
- <a href="http://sites.google.com/site/snehalantani/designingBatchApps.zip" rel="nofollow">http://sites.google.com/site/snehalantani/designingBatchApps.zip</a><br />
- <a href="http://sites.google.com/site/snehalantani/DesigningBatchApplications.pdf" rel="nofollow">http://sites.google.com/site/snehalantani/DesigningBatchApplications.pdf</a></p>
<p>Batch processing infrastructure overview:<br />
- <a href="http://sites.google.com/site/snehalantani/WebSphereDataIntensiveApps.pdf" rel="nofollow">http://sites.google.com/site/snehalantani/WebSphereDataIntensiveApps.pdf</a><br />
- <a href="http://www-128.ibm.com/developerworks/websphere/techjournal/0804_antani/0804_antani.html" rel="nofollow">http://www-128.ibm.com/developerworks/websphere/techjournal/0804_antani/0804_antani.html</a></p>
<p>Customer experience with modern batch processing:<br />
- <a href="http://www-01.ibm.com/software/tivoli/features/ccr2/ccr2-2008-12/swissre-websphere-compute-grid-zos.html" rel="nofollow">http://www-01.ibm.com/software/tivoli/features/ccr2/ccr2-2008-12/swissre-websphere-compute-grid-zos.html</a></p>
<p>Latest Compute Grid overview presentation:<br />
- <a href="http://sites.google.com/site/snehalantani/latestpresentationmaterial" rel="nofollow">http://sites.google.com/site/snehalantani/latestpresentationmaterial</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
