|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 5
By default, the splitter uses the first list or Array argument of the invocation as the identifiers. Parallelism and batch size are two other important configurable parameters which define number of parallel threads and batch size of the id collection in each thread.
The IdsIterator interface is responsible for splitting the identifiers collection into chunks. The BarrierResult interface then processes each chunk independently and combines the result of each execution into the final output. Concrete
implementations for IdsIterator and BarrierResult are dynamically loaded by the Splitter Factory. This dynamic resolution depends on the identifier collection and result types.
Currently splitter supports List and Array classes for the identifiers and Void, Map, List and XML input stream for the execution
results. Descendents of these classes are supported automatically. Any other implementations of the identifiers and return
type could be easily configured by the user on per-case basis. Extending Splitter
Splitter will understand and work with generic parameters and return types such as List, Map, String arrays, and Void. In
real life however, it should deal with custom-made types in each specific application. Splitter is designed in such a way
that adding support for additional parameter or return types is easy.
Adding a new parameter type entails taking the following steps. First, write a class which implements the interface IdsIterator<IDS>. This will usually be a descendent of IdsIteratorBaseImpl<IDS>. This class implements the process of splitting the parameter objects into batches.
The method nextBatch() must be synchronized. It should return a Batch object containing a subset of the items (identified by ids) to be processed.
The first call to nextBatch() must start at the beginning of the original item set and subsequent calls must return consecutive subsets.
The method getApplicableClasses() should return an array containing the classes to which the new idsIterator will apply (descendents to these classes will work automatically and do not need to be listed separately).
For descendents of IdsIteratorBaseImple<IDS>, the method sizeForIds (Object ids) should return the number of ids provided in the ids object.
The second step is to add a bean declaration for this implementation class to the project's Spring context file. For example:
<bean id="idsIteratorArray" class="net.sourceforge.offsprings.splitter.impl.IdsIteratorArrayImpl" singleton = "false" />
Third, add a value to the idsIterators property of the splitterFactory in the defaultSplitterContext.xml file referencing the newly created bean. For example:
<value>idsIteratorArray</value>
Follow these steps to add a new return type. First, write a class which implements the interface BarrierResult. (Generally, this will be a descendent of BarrierBaseImpl.) This class implements the process of merging the various batches. The method getApplicableClasses() should return an array containing the classes to which the new idsIterator will apply (descendents to these classes will work automatically and do not need to be listed separately). For descendents
of BarrierBaseImpl, the method merge() should merge the results from each batch (stored in the protected attribute _results) into a single object of the appropriate type.