Asynchronous with respect to sending transactions. Since messages are
across entities, the data associated
with the decision to send the message
is in one entity, and the destination of
the message is in another entity. By definition of an entity, these entities cannot be atomically updated. Messages
cannot be atomically sent and received
across these different entities.
It would be horribly complex for an
application developer to send a message while working on a transaction,
have the message sent, and then the
transaction abort. This would mean
you have no memory of causing something to happen and yet it does happen. For this reason, transactional en-queuing of messages is de rigueur (see
If the message cannot be seen at
the destination until after the sending
transaction commits, the message is
asynchronous with respect to the sending transaction. Each entity advances
to a new state with a transaction. Messages are the stimuli coming from one
transaction and arriving at a new entity
Naming the destination of messages. Consider the programming of
the scale-agnostic part of an application, as one entity wants to send a
message to another entity. The location of the destination entity is not
known to the scale-agnostic code.
The entity key is.
It falls on the scale-aware part of the
application to correlate the entity key
to the location of the entity.
Repartitioning and message delivery.
When the scale-agnostic part of the application sends a message, the lower-level scale-aware portion hunts down
the destination and delivers the message at least once.
As the system scales, entities move.
This is commonly called repartitioning.
The location for the entity and, hence,
the destination for the message may be
in flux. Sometimes messages will chase
to the old location only to find out the
pesky entity has been sent elsewhere.
Now the message will have to follow.
As entities move, the clarity of a
first-in, first-out queue between the
sender and the destination is occasionally disrupted. Messages are repeated.
Later messages arrive before earlier
ones. Life gets messier.
For these reasons, scale-agnostic
applications are evolving to support
idempotent processing of all applica-tion-visible messaging. This implies
reordering in message delivery, too.
Activities: Coping with
This section discusses ways of coping
with the challenges of message retries
Figure 4. Under scale, alternative index entries land elsewhere.
unique primary key
PK:123 PK:217 PK:332 PK:589 PK:719
1st alternate key
A1:DEF A1:ABC A1:GHI A1:JKL A1:MNO
2nd alternate key
A2:def A2:aba A2:fgh A2:ghu A2:klw
Figure 5. Messages flow from one entity