Issue 5913: current write operation (lwlog-ftf) Source: THALES (Ms. Virginie Watine, virginie.watine(at)thalesgroup.com) Nature: Uncategorized Issue Severity: Summary: The current write operation only has on parameter (ProducerLogRecordSequence) that allows a sequence of log records to be written. add an additional write operation with a simple parameter that allows a single log record to be written and does not require a sequence. Resolution: Revised Text: Actions taken: April 23, 2003: received issue Discussion: End of Annotations:===== Logging Issues Source: THALES (Ms. Virginie Watine, virginie.watine@fr.thalesgroup.com) Nature: Ease of Use Severity: minor interface addition Summary: The current write operation only has on parameter (ProducerLogRecordSequence) that allows a sequence of log records to be written. add an additional write operation with a simple parameter that allows a single log record to be written and does not require a sequence. Resolution: Revised Text: Actions taken: Discussion: X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Apr 2003 11:49:21 -0400 To: lwlog-ftf@omg.org From: Victor Giddings Subject: Proposed Resolution for issue 5913 At 03:48 PM 4/24/2003 -0400, Juergen Boldt wrote: This is issue # 5913 Ms. Virginie Watine, virginie.watine@fr.thalesgroup.com current write operation The current write operation only has on parameter (ProducerLogRecordSequence) that allows a sequence of log records to be written. add an additional write operation with a simple parameter that allows a single log record to be written and does not require a sequence. Further Discussion: I agree that this is needed. There is significant overhead in several languages to forming a sequence that is unnecessary if the sequence length is 1. For example, in Java it requires the allocation of an array of length 1, and in Ada, it requires not only the allocation of an array, but also a copy of the contents. Proposed Resolution: Add new section 2.5.1: 2.5.1 writeRecord Writes a single record to the Log. Synopsis + writeRecord (in record : ProducerLogRecord) Parameters and Return Exceptions This operation raises no exceptions. Description The writeRecord operation adds a single log record supplied in the record parameter to the Log. When there is insufficient storage to add one of the supplied log records to the Log, and the LogFullAction is set to HALT, the writeRecord operation shall set the availability status logFull state to true. The writeRecord operation inserts the current UTC time to the time field of the record written to the Log, and assigns a unique record Id to the id field of the LogRecord. All log records accepted for storage by the writeRecord will be available for retrieval in the order received. Parameter Type Description record ProducerLogRecord The record to be written to the log. Add the following operation to the IDL in section 3.3.3: oneway void write_record(in ProducerLogRecord record); Add the following new section 3.3.3.1: 3.3.3.1 write_record Writes a single record to the Log. Parameters and Return Exceptions This operation raises no exceptions. Description The write_record operation adds a single log record supplied in the record parameter to the Log. When there is insufficient storage to add one of the supplied log records to the Log, and the LogFullAction is set to HALT, the write_record operation shall set the availability status logFull state to true. The write_record operation inserts the current UTC time to the time field of the record written to the Log, and assigns a unique record id to the id field of the LogRecord. All log records accepted for storage by the write_record will be available for retrieval in the order received. Note , to de-couple the log producer from the logging service implementation, so that difficulties in the Log have no side-effects on the log producer or its operation. However, since ORBs may legally discard oneway requests, implementers should take extra care that the onway invocations of write_record are not discarded without very substantial reason. Mapping from the Platform Independent Model This IDL operation definition is the result of a one-to-one mapping from operation writeRecord, defined in the UML class Log and made visible through interface LogProducer in the PIM (See Section 2.5.1 , on page 2-14). The spelling of the operation name has been changed to conform to the OMG IDL Style Guide. Parameter Type Description record ProducerLogRecord The record to be written to the log. Section 4: Add the following to the LogProducer interface in the IDL: oneway void write_record(in ProducerLogRecord record); Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 Issue 5913: current write operation (lwlog-ftf) Click here for this issue's archive. Source: THALES (Ms. Virginie Watine, virginie.watine@fr.thalesgroup.com) Nature: Uncategorized Issue Severity: Summary: The current write operation only has on parameter (ProducerLogRecordSequence) that allows a sequence of log records to be written. Recommendation: add an additional write operation with a simple parameter that allows a single log record to be written and does not require a sequence. Resolution: Revised Text: Actions taken: April 23, 2003: received issue Discussion: From Victor - I agree that this is needed. There is significant overhead in several languages to forming a sequence that is unnecessary if the sequence length is 1. For example, in Java it requires the allocation of an array of length 1, and in Ada, it requires not only the allocation of an array, but also a copy of the contents. Proposed Resolution - Accept proposed recommendation Proposed Revised Text - In the document Lightweight Log Service Specification - OMG Final Adopted Specification ptc/03/04/01 Add new section 2.5.2: 2.5.2 writeRecord Writes a single record to the Log. Synopsis + writeRecord (in record : ProducerLogRecord) Parameters and Return (ADD TABLE WITH parameters record ProducerLogRecord The record to be written to the log. and ,, This operation does not return a value) Exceptions This operation raises no exceptions. Description The writeRecord operation adds the log record supplied in the record parameter to the Log. When there is insufficient storage to add the supplied log record to the Log, and the LogFullAction is set to HALT, the writeRecord operation shall set the availability status logFull state to true. The writeRecord operation inserts the current UTC time to the time field of the record written to the Log, and assigns a unique record ID to the id field of the LogRecord. Log records accepted for storage by writeRecord will be available for retrieval in the order received. Add the following operation to the IDL in section 3.3.3: oneway void write_record(in ProducerLogRecord record); Add the following new section 3.3.3.2: 3.3.3.2 write_record Writes a single record to the Log. Parameters and Return (ADD TABLE WITH parameters record ProducerLogRecord The record to be written to the log. and void This operation does not return a value) Exceptions This operation raises no exceptions. Description The write_record operation adds a log record supplied in the record parameter to the Log. When there is insufficient storage to add the supplied log record to the Log, and the LogFullAction is set to HALT, the write_record operation shall set the availability status logFull state to true. The write_record operation inserts the current UTC time to the time field of the record written to the Log, and assigns a unique record ID to the id field of the LogRecord. Log records accepted for storage by write_record will be available for retrieval in the order received. Note - The purpose of the oneway invocation is, within the limitations of embedded ORBs, to de-couple the log producer from the logging service implementation, so that difficulties in the Log have no side-effects on the log producer or its operation. However, since ORBs may legally discard oneway requests, implementers should take extra care that the onway invocations of write_record are not discarded without very substantial reason. Mapping from the Platform Independent Model This IDL operation definition is the result of a one-to-one mapping from operation writeRecord, defined in the UML class Log and made visible through interface LogProducer in the PIM (See Section 2.5.2, "writeRecord," on page XXX). The spelling of the operation name has been changed to conform to the OMG IDL Style Guide. Difference to the Telecom Log Service This is a new operation, not available in the Telecom Log Service. It reflects the architectural and operational difference between the two services. Section 4: Add the following to the LogProducer interface in the IDL: oneway void write_record(in ProducerLogRecord record); Subject: RE: Issue Resolution Poll 2 Date: Thu, 1 May 2003 11:32:20 -0400 Thread-Topic: Issue Resolution Poll 2 Thread-Index: AcMP83rxR6fRI3vmEdeMjACgyTbmFwAAN5EQ From: "Pilhofer, Frank" To: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h41FXseK031726 > > Enclosed is a set of comments and proposed resolutions for the second > set of issues. > Hi, some discussion: Issue 5767: I don't agree with the resolution. The added operations need (a) a currentId input, and (b) a means to limit the returned sequence. Well, I feel very strongly about (a), not quite as strongly about (b). My original suggestion was to model the new operations after get_record_id_from_time. But we might as well model them after retrieve_by_id, if that finds more consensus. In any case, the client needs ways to - find records with the desired feature - avoid the download of unwanted records - avoid having to download the same record twice My suggestion enabled that. My alternative suggestion, modeling after retrieve_by_id, would add operations like retrieve_by_level (inout currentId: RecordId, inout howMany: unsigned long, in valueList LogLevelSequence) : LogRecordSequence I'm fine with either approach, but not with the proposed resolution. Issue 5913: I disagree with the "oneway"-ness. In fact, I should add an issue to remove the oneway from the write_records operation as well. The semantics of oneway are undefined. It shouldn't be used, period. Because oneway is already in there, I guess I can agree to this change, with the introduction of a new issue about abolishing oneway from the spec. No complaints about the other issues and their resolution. Good work, Kevin. Frank