AW: [smila-dev] RE: FYI :: new feature :: Message Resequencer

[<Igor.Novakovic@xxxxxxxxxxx>]

Hi,

> Anyhow: I think we can safely assume these axioms now:
> 
> a) if we have shared records by using a persisting BB then it follows
that in
> general we must not allow to have several PRs for the same resource in
the
> workflow/processing chain. This has nothing to do with the order, just
with
> concurrency bugs.
+1



> b) if we have a transient BB and the record is not shared then it is
sufficient to
> bring things into order at the end, which is the core idea behind the
SRS.
Transient BB can actually only be reasonable used in the information
retrieval process (i.e search) since there all operations are executed
on the query and the result object. It is also important to note that
this process is currently synchronous. (No queues - just a direct call
of some specific pipeline.)

On the other hand, using the persisting BB is a must when executing the
preprocessing which actually operates on real documents/records. (BTW
this process is asynchronous.) The reason for this lies on the hand: You
will (almost) always have to store at least the content of the document
in the binary storage. The very rare exception is the case where the
documents are so small so that they fit completely (metadata and
content) in a queue message. Here we could avoid the storing of them (by
calling BB in Connectivity). In that case we must use transient BB in
our preprocessing pipelines and take care of the execution order.


Regards
Igor