Why do gaps appear in the incident numbering sequence?

Version 1

    Details

    PROBLEM
    When evaluating all incidents or requests in an instance of LiveTime, you might notice that there are gaps in the IDs for incidents or other records which have IDs associated with them (e.g. you might see incidents numbered 1, 2, 10, and 11 during testing of a new LiveTime installation when there are only four incidents.)

    ENVIRONMENT
    LiveTime

    RESOLUTION
    The discrepancies, gaps, or missing incidents / requests / IDs in an installation of LiveTime are by design and revolve around how the LiveTime counters are stored in memory.

    LiveTime stores a value in the eo_pk_table table in the LiveTime database that keeps track of how many records have been created for any given ID. For every 10 IDs generated by LiveTime, the value in the eo_pk_table for that ID is incremented by 1 (e.g. a value of 4 in the eo_pk_table equates to an ID range of 40-49).

    The behavior described is caused by LiveTime incrementing this value when LiveTime first starts. The reason this occurs is that the counter itself is stored in memory, and to prevent ID's from being re-used, LiveTime will increment the eo_pk_table value by 1 when starting.

    In the example of IDs being 1, 2, 10 and 11, this indicates that LiveTime was restarted after records with IDs 1 and 2 were created. Upon restart, LiveTime increments the eo_pk_table value from 0 to 1, and starts the counter for new incident numbers at 10 from which incident 10 and 11 are then created.


    ADDITIONAL INFORMATION
    Even though the counter is stored in memory, the database record is still updated for each 10 records that are created while in use. This ensures data integrity in case LiveTime stops suddenly or unexpectedly.

    The main reasons for storing the counters in memory are:

    1. To limit the number of reads and writes to the LiveTime database while in use. By doing it this way, the number of reads/writes to the LiveTime database are reduced by at least 90% while new records are being created (only one out of every 10 new records writes to eo_pk_table). In addition, since counters are stored in memory, LiveTime never needs to read the LiveTime database to find out what IDs are used / available while in use. LiveTime only needs to check the database for the record IDs when first starting.

    2. To improve performance when LiveTime starts. Instead of checking and storing in memory the highest ID available for all record IDs available in LiveTime (which are all stored in their own individual tables), the values are simply collected and incremented from a single table (eo_pk_table), which provides a significant performance savings.


    Resolution

    PROBLEM
    When evaluating all incidents or requests in an  instance of LiveTime, you might notice that there are gaps in the IDs  for incidents or other records which have IDs associated with them (e.g.  you might see incidents numbered 1, 2, 10, and 11 during testing of a  new LiveTime installation when there are only four incidents.)

    ENVIRONMENT
    LiveTime

    RESOLUTION
    The  discrepancies, gaps, or missing incidents / requests / IDs in an  installation of LiveTime are by design and revolve around how the  LiveTime counters are stored in memory.

    LiveTime stores a value  in the eo_pk_table table in the LiveTime database that keeps track of  how many records have been created for any given ID. For every 10 IDs  generated by LiveTime, the value in the eo_pk_table for that ID is  incremented by 1 (e.g. a value of 4 in the eo_pk_table equates to an ID  range of 40-49).

    The behavior described is caused by LiveTime  incrementing this value when LiveTime first starts. The reason this  occurs is that the counter itself is stored in memory, and to prevent  ID's from being re-used, LiveTime will increment the eo_pk_table value  by 1 when starting.

    In the example of IDs being 1, 2, 10 and 11,  this indicates that LiveTime was restarted after records with IDs 1 and 2  were created. Upon restart, LiveTime increments the eo_pk_table value  from 0 to 1, and starts the counter for new incident numbers at 10 from  which incident 10 and 11 are then created.


    ADDITIONAL INFORMATION
    Even  though the counter is stored in memory, the database record is still  updated for each 10 records that are created while in use. This ensures  data integrity in case LiveTime stops suddenly or unexpectedly.

    The main reasons for storing the counters in memory are:

    1.  To limit the number of reads and writes to the LiveTime database while  in use. By doing it this way, the number of reads/writes to the LiveTime  database are reduced by at least 90% while new records are being  created (only one out of every 10 new records writes to eo_pk_table). In  addition, since counters are stored in memory, LiveTime never needs to  read the LiveTime database to find out what IDs are used / available  while in use. LiveTime only needs to check the database for the record  IDs when first starting.

    2. To improve performance when LiveTime  starts. Instead of checking and storing in memory the highest ID  available for all record IDs available in LiveTime (which are all stored  in their own individual tables), the values are simply collected and  incremented from a single table (eo_pk_table), which provides a  significant performance savings.