Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SMILA/Specifications/Partitioning Storages
Use Case: Partitioning both Storages for Backup and Reuse/Recrawling
- Changes in XML and Bin storage.
- To support partitioning both XML- and Bin- storages must be able to store data to partitions. Thus XML- and Bin- storage APIs should be extended in such way that partition information will be accepted as an additional parameter when saving data. With binstorage, binary attachments can have quite a big size, thus if attachment wasn't changed from one partition to another, it's worth not to copy attachment's data for each partition but store only reference to actual attachment.
- Partitioning configuration and changes in Blackboard API.
- Partition information (partition name) can be configured into Listener Rule.
- There are following ways of how to pass partition information:
- 1. Partition information is passed as a record Id property.
- Listener gets record from the queue and sets partition property to the Id.
- Blackboard uses parition information in load and commit operations.
- In this case no signifant changes are required to the blackboard API because partition information is incapsulated into record Id.
- 2. Partition information is passed separately from record as a JMS property.
- Listener reads JMS property from the queue and makes it available for other components that will use blackboard (like processing).
- In this case all methods from blackboard API should be duplicated to handle partition name as a second parameter.
- The first option seems to be more useful because it allows to keep partition information directly into the record and thus easily #:pass and receive it between distributed components.