LtLOG 1.1 NO IDEA Avatar
  1. OMG Issue

LTLOG11 — issue with section 2.4.2 retrieveById

  • Key: LTLOG11-28
  • Legacy Issue Number: 5885
  • Status: open  
  • Source: ADLINK Technology Ltd ( Vincent Kovarik)
  • Summary:

    We have implemented the above service as part of our SCA Core Framework
    implementation. However, we have an issue with section 2.4.2 retrieveById of
    the document.

    This section states (we have numbered the sentences in question):

    S1: "The log will update howMany to indicate the number of records returned and
    will set currentId to the id of the record following the last retrieved record.

    S2: "If there are no further records available, currentId will be set to zero."

    S3: "If the record specified by the currentId does not exist, or if the Log is
    empty, the retrieveById operation returns an empty list of LogRecords, and sets
    both, currentId and howMany to zero."

    This behavior can create a problem as follows.

    1) A log is operational with 10 records, Id 1 through 10.

    2) An application issues a retrievById request for 5 logs starting at ID 6.

    3) The log retrieves records 6 through 10, updates the howMany to 5, and sets
    the currentId to 11, per S1 above

    NOTE: At this point it is unclear if S2 applies. Certainly, at this point in
    time, no more records are available but setting currentId to zero is in conflict
    with S1 and doesn't appear to make sense. The following steps assume that S1 is
    followed and S2 is ignored.

    4) The log is still operational but has not written any additional records when
    the same application issues a retrievById for 10 records starting at record id
    11 (what it believes to be the next record).

    5) The currentId of 11 does not exist in the log, so S3 applies. Consequently,
    the log returns an empty set of LogRecords and sets both howMany and currentId
    to zero.

    6) The application now believes the currentId in the log has been reset to zero.

    7) The log writes records 11 through 14.

    At this point the application has lost a valid reference into the log to obtain
    the next record by Id.

    We would like to recommend the following changes to the retrieveById .

    S1: No Change

    S2: Strike from the paragraph.

    S3: Strike as worded and add the following conditions:

    S3.A) If the record specified by currentId does not exist AND the currentId
    provided by the call is greater than the Id of the last record written by the
    log, the retrieveById operation returns an empty list of LogRecords, sets
    howMany to zero, and leaves the currentId unchanged.

    S3.B) If the record specified by currentId does not exist AND the currentId
    provided by the call is zero OR less than the first Id of the log, the
    retrieveById operation returns an list of LogRecords starting with the first
    available records, sets howMany to the number of records retrieved, and sets the
    currentId to one past the last record retrieved.

    S3.C) If the record specified by currentId does not exist and the Log is empty,
    the retrieveById operation returns an empty list of LogRecords, sets hoMany to
    zero, and sets the curentId to zero.

    Change S3.A allows a client to request log records and leave the currentId
    pointing the next log record in the eent that at the time of the retrievById
    operation, there were no log records available but the log is operational and
    just had not written any additional records since the applications last request.

    Change S3.B addresses the scenarios where the client may have a Id reference
    that has been written and cleared since it's last retrieveId request and the
    first available log Id is greater than the Id requested. It also provides the
    mechanism for allowing a client to issue a retrieveById without knowing the
    current state of the log and obtain the first set of available log records.

    Change S3.C identifies the empty log condition to the application as opposed to
    simply no further records available at the time of the call.

  • Reported: LtLOG 1.0b1 — Wed, 19 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT