SMILA/Specifications/Processing Message Resequencer/Record Version Number

introduction

this idea builds on juergen's version attribute and the way ORM solutions detect stale writes to a record in a DB.

note: i should rename SN to VN but i stick to SN to avoid having another abbreviation.

working principle

1. each PR gets an SN
2. the SN is transient and not part of the actual record. its a processing meta information such as DEL, ADD.
3. when accessing records via the BB
   1. the associated SN must be included in the call to the BB.
   2. the BB checks the given SN against and the stored SN
   3. if the stored SN is greater than the given SN the access/operation fails b/c it is certain that a new PR for the item was created
4. in addition to this, the listeners and/or the pipelet/service managers could remove such PRs before/after the process() call

PRO

• with this concept we can allow several PRs at the same item in the workflow as these sort out fairly quickly by themselves.
• in addition we could still install a buffer in connectivity to consolidate PRs but i dont think that is needed and it require the feedback that processing is done.

CON

• this solution is limited to persisting BBs and to the scope of shared record. clustering will need the BB to be clustered as well.
  this can be solved by storing the record/SN association not in the RecordStore but elsewhere which then is clustered.
• it is quite an API change:
  • piplets and services are not just given an Id[] array but a new class that wrapps the ID plus the SN. an alternative is to put the SN into the Id class but not persist it or at least handle it specially such as is done with the hash already. the latter would be a less taxing change in regard to method signatures. the semantic change is still considerable.
  • implementers of pipelets and services need to know that a record that was ok at the beginning of processing may not be anymore later on and need to react accordingly. namely: it is not a normal processing exception where the item then ends up in the DLQ but a situation that may occur by design an no further error reporting is needed (except for a log entry to be aware of the cancellation of the older PR).
  • the BB should signal this by throwing a new special Exception such as NewerVersionException. instead of such an exception we could just tell implementers to call special check methods or return null/NullObjects but these are less safe/verbose IMO.