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
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
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.