Reservation

The purpose of reservations in Anyblok / WMS Base is two-fold:

  • functionally, it’s about making sure that The PhysObj Model: Physical Objects that are essential to some purposes stay available for them (as much as possible, of course)
  • technically, it collapses contention onto a relatively simple problem that, once solved, allows the rest of the application to work in parallel without much trouble.

Reservation Request

This is the cornerstone of the reservation system.

These represent (and link together) what it is needed to reserve, and for what purpose.

They can be issued freely by all subsystems when new needs arise. It shouldn’t lead to contention problems, as they are simply inserted in the database, and are mostly inert at that point.

They get enforced as Reservations, typically by a Reserver service. From that point on, they represent limitations on what can be done about the corresponding The PhysObj Model: Physical Objects, and get fed to Planners as work specifications.

Reservation Requests are actually made of several Request Items.

See also

the code documentation.

Reservation

A Reservation binds some The PhysObj Model: Physical Objects to a Reservation Request Item.

Once thus reserved, new Operations can’t be done or planned for these The PhysObj Model: Physical Objects unless either:

  • the current database transaction has claimed ownership of the reservations of the corresponding Request (this is meant for Planners)
  • the Operation is in a restricted list of authorized ones (this probably won’t be implemented before version 0.7). The idea is to still allow some Operations (for instance a short range Move for rack reorganisation shouldn’t be prevented if the same The PhysObj Model: Physical Objects are supposed to leave the system later on.

See also

the code documentation.