View Source

Dynamic license reservations let you optimize license usage by reserving required licenses in advance. In this way, you can ensure there are no license usage denials, no gaps in license usage, and no under-utilization of licenses.

Dynamic license reservations work only with virtual and terminal server sharing; they do not work with user, host or custom sharing.

Unlike a normal checkout/checkin, a reservation performed by one client can be consumed by any other client, including a different physical machine.
You can use reservations in the following ways:

You can do both a checkout and a reservation for the same feature only when using different LM-X handles for each action.
You can do multiple reservations for one feature using a different token for each reservation.
You can use one token to reserve multiple individual features.
You can make multiple reservations for an individual feature using one token. Each additional call of LMX_Admin_Reserve will increase the amount of reserved licenses by the given count. Reservation expire time will be overwritten by the last call of LMX_Admin_Reserve.
Reservations do not work with token-based licenses. Attempting to reserve a token-based license will return LMX_NOT_IMPLEMENTED. If licenses with the same name are a mix of token-based and normal licenses, LM-X can differentiate between them to use a valid license for a reservation.

If you consume (checkout) a reservation and then later do a return (checkin), the licenses will be returned to the reservation pool, not to the general license pool. You can checkout and checkin a reservation multiple times using multiple clients, and the reservation pools will be maintained. The reservation remains valid until it expires or is explicitly returned using LMX_Admin_ReserveEarlyReturn.

For example, a job scheduler handling batch jobs could reserve a license using reservation token 9876 for a specific length of time, say 10 minutes. Within that reservation time, the batch job application can then consume (checkout) the reservation by providing reservation token 9876 to the license server. This ensures that the application requiring the checkout will be able to get a license when needed.

A standard workflow for implementing dynamic license reservations is as follows:

A job scheduler uses LMX_Admin_Reserve to do the reservation on behalf of another application.
With a successful reservation, the scheduler passes on the reservation token to the client application when the application is ready.
Using the LMX_SetOption flag LMX_OPT_RESERVATION_TOKEN together with LMX_Checkout, the client application consumes the license.

The following table shows an example progression of how licenses are reserved and consumed. This example is for a single feature with a pool of 10 licenses.

Action	Licenses in Pool	Reserved Licenses	Licenses Consumed by Client 1	Licenses Consumed by Client 2
Default state, before reservations/consumptions	10	0	0	0
Reserve 8 licenses of feature using token ABC	2	8 using token ABC	0	0
Reserve 2 licenses of feature using token XYZ	0	8 using token ABC; 2 using token XYZ	0	0
Any client attempts normal checkout of 1 license (returns LMX_NOT_ENOUGH_LICENSES)	0	8 using token ABC; 2 using token XYZ	0	0
Client 1 consumes 1 reservation using token ABC	0	7 using token ABC; 2 using token XYZ	1 using token ABC	0
Client 2 consumes 1 reservation using token XYZ	0	7 using token ABC; 1 using token XYZ	1 using token ABC	1 using token XYZ
Client 1 consumes 5 reservations using token ABC	0	2 using token ABC; 1 using token XYZ	6 using token ABC	1 using token XYZ
Client 2 attempts normal checkout of 1 license (returns LMX_FEATURE_ALREADY_RESERVED)	0	2 using token ABC: 1 using token XYZ	6 using token ABC	1 using token XYZ
Client 1 checks in all licenses	0	8 using token ABC: 1 using token XYZ	0	1 using token XYZ
Client 2 performs early return using token XYZ	2	8 using token ABC	0	0
Client 2 performs early return using token ABC	10	0	0	0