Issue 3753: current_version() (daf_ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: By way of background, our DAF implementation is based on J2EE and Enterprise Java Beans stored in an Oracle database. Our data provider will be transactional. I'm a little unclear on what the integer value for current_version() needs to return. Section 5. Events says that a version number is a unique integer assigned to each data change. A data provider may issue either general or specific data change events, depending on circumstances. The way I'm reading this, any time that any of the data served up by the data provider changes the version gets incremented. Is this correct? Or are there extenuating circumstances that affect the version numbering?? If the data provider is serving up data based on data changes that are coming in via messages, won't the version number be changing a lot? Resolution: Revised Text: 2.1.2 Recommendation The recommended solution is to separate the event reporting and the concurrency conflict detection as follows: · Event reporting will only be available via the CosEvent-based interfaces. It will not be possible to poll current_version() to reliably detect a change. · The contract of the current_version() method can then be modified to provide a inconsistent read detection required by data providers of type (2) above without affecting data providers of type (1) or (3). · No change is recommended to support fine-grained events. Events remain on a per-class or global basis, which is in accordance with the RFP requirements. A future specification, perhaps using CORBA Notification or other event technology could deal with fine-grained events and their subscription criteria. The following changes are recommended, as per [1]: · The ResourceChangeEvent::version field is removed. (Section 5.) · The contract of current_version() is changed so that a data provider of type (1) or (3) can effectively opt-out of the protocol and implementation is easier for a data provider of type (2). · The return type of current_version() is changed to unsigned long long so that time stamps can be used for versions if desired. · The discussion is changed accordingly. (Section 5.2.) · The behaviour of proxy data providers is changed (Section 7.4.) Page numbers affected: 37, 38, 39, 40, 42, 43, 49. Actions taken: July 20, 2000: received issue May 24, 2001: closed issue Discussion: The provision in the event specification that associates version numbers with updates to the server's state is undesirable. These version numbers are conveyed to the client by the current_version() operation as well as via events. The original motivation for this was twofold: · Provide a means for an application, such as a State Estimator, to poll for changes in the model. This is an alternative to listening to the event interface. · Determine if a model change took place during the reading/navigating process, thus indicating that the data read might be inconsistent. The version number approach creates a bottlneck for transactional systems, as every transaction must contend for the current version datum. And it is not easy to implement in non-transactional systems, as each change must be intercepted and cause the current version to be incremented. Furthermore, it is not clear what value should be returned by a data provider that enters a long-lasting, inconsistent state. An improved solution needs to accommodate three types of data provider: 1. Transactional data providers e.g. based on Oracle. These should be able to opt out of the version protocol. A DAF interface wrapping an Oracle system could offer full CORBA transaction support. 2. Non-transactional data providers. This is a large class of potential implementations including implementations that wrap the real-time portion of a typical EMS system. For these, some protocol is required to detect infrequent model changes that collide with model access. If a collision is occasionally detected the client can retry its query sequence. 3. Real-time data providers. This type of data provider will update frequently, but in such a way that clients never see inconsistent data. For example, individual voltage values may change constantly but clients need not be concerned about moderate time skew as they acquire a set of voltage values. Neither transaction support nor the version protocol is required. A client must work unchanged with any of the foregoing kinds of data provider. End of Annotations:===== X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 16:39:49 -0500 To: daf_ftf@cme.nist.gov From: Leila Schneberger Subject: current_version() Mime-Version: 1.0 Sender: owner-daf_ftf@cme.nist.gov Precedence: bulk Reply-To: daf_ftf@cme.nist.gov Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ''0e9$Y]d9KINe9G\3!! Hello, By way of background, our DAF implementation is based on J2EE and Enterprise Java Beans stored in an Oracle database. Our data provider will be transactional. I'm a little unclear on what the integer value for current_version() needs to return. Section 5. Events says that a version number is a unique integer assigned to each data change. A data provider may issue either general or specific data change events, depending on circumstances. The way I'm reading this, any time that any of the data served up by the data provider changes the version gets incremented. Is this correct? Or are there extenuating circumstances that affect the version numbering?? If the data provider is serving up data based on data changes that are coming in via messages, won't the version number be changing a lot? Thanks, Leila From: "Arnold deVos" To: "DAF FTF" Cc: "John Gillerman" , "Steve Widergren" , "Dmitry Farberov" , "Earl Coombs" References: <4.3.2.7.2.20000720161259.03494ac0@pop3.sihope.com> Subject: Re: current_version() Date: Fri, 21 Jul 2000 19:23:44 +1000 Organization: Langdale Consultants MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-daf_ftf@cme.nist.gov Precedence: bulk Reply-To: daf_ftf@cme.nist.gov Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j'Q!!$B*e9clP!!o/ld9 Hi Leila, The events and current_version() behaviour was raised as an issue by the AB. It is not a strong part of the spec and I want to change it in the FTF. Although it seems pretty hokey it is not possible to get rid of it entirely, without going to full transactions. But that cannot be supported by a large class of implementations (the realtime part of your typical EMS!). The original purpose of current_version() was to: (1) provide a means for an application, such as a State Estimator, to poll for changes in the model. This is an alternative to listening to the event interface. (2) determine if a model change took place *during* the reading/navigating process. As currently specified current_version() creates a bottlneck for transactional systems, as every transaction must contend for the current version datum. And its not-too-kind for non-transactional systems, as each and every change must be intercepted and cause the current version to be bumped. I think the answer is to separate the event reporting and the concurrency conflict detection. A transactional data provider, e.g. based on Oracle (TM), does not need the latter function and should be able to opt out of this strange current_version() protocol. Perhaps we can rewrite parts of section 5 in the spec along the following lines (although I need to tighten up some of the language)... 5 Events -------- [...] version This field is deprecated and will be removed from the specification. [...] current_version() This operation is used by clients to detect concurrency conflicts. A client should query the current version before and after issuing a set of queries. If the values are equal and non-zero then the query results are taken to be self-consistent. Section 5.2 elaborates on this protocol and its motivation. [...] 5.2 Current Version and Transactions ------------------------------------- The DAF interfaces are intended to be useful for a wide variety of data providers with and without transaction support. The DAF interfaces may be used in conjunction with CORBA Transactions where the data provider supports transactions. On the other hand, DAF interfaces can be used by realtime, legacy, or other systems where conventional concurrency control techniques are unsuitable. In that case the current_version() protocol must be supported, as described in the next section. 5.2.1 Non-transactional Data Providers If the data provider does not support transactions, then a client may be exposed to inconsistent query results in at least two ways: (a) In some data providers, the transition from one consistent state to another may expose a series of intermediate, inconsistent states. If such a data provider is queried while in an intermediate state, it may return inconsistent results. (b) Even if no intermediate states are exposed, a client may obtain inconsistent data if a set of queries span two or more states of the data provider. Each state is self-consistent, but query results combined from both are not. The states are mutually inconsistent. If either (a) or (b) obtain for a data provider, it must support the following protocol so that a client can detect inconsistent query results. (i) The client invokes current_version(), which returns X. (ii) The client completes two or more operations via the ResourceQueryService interface. (iii) This client invokes current_version(), which returns Y. (iv) The data provider guarantees that the query results obtained in (ii) are consistent if and only if X equals Y and X is non-zero. Note that this protocol does not require current_version() to indicate every change of state. The event mechanism should be used to track state changes. 5.2.1.1 Implementation Examples - If neither (a) nor (b) obtain for a data provider then query results are always considered consistent. In this case, it is recommended that the current_version() operation always return the value 1. - If a data provider exposes an intermediate state as per (a) for long enough that a complete sequence (i) through (iv) could be completed, then it is recommended that current_version() operations return the value zero at (i) and (iii). - If a data provider exposes a series of updates at step (ii) but they are considered consistent viewed in any combination, it is recommended that the current_version() operations return the same non-zero value at (i) and (iii). - If a data provider transitions through a series of states considered mutually inconsistent as per (b), it is recommended that current_version() return successive non-zero integers in the successive states such that if current_version() values agree at (i) and (iii) then the entire sequence is contained in one such state. If the values disagree it is indeterminate whether queries at (ii) spanned two mutually inconsistent states. 5.2.2 Transactional Data Providers A transactional data provider implements the CORBA Transactions specification. The current_version() protocol is not required in this case. The current_version() operation should return a constant non-zero integer for every invocation. It is recommended that the value 1 is returned. ----- Original Message ----- From: Leila Schneberger To: Sent: Friday, July 21, 2000 7:39 AM Subject: current_version() > Hello, > By way of background, our DAF implementation is based on J2EE and > Enterprise Java Beans stored in an Oracle database. Our data > provider will > be transactional. I'm a little unclear on what the integer value for > current_version() needs to return. Section 5. Events says that a > version > number is a unique integer assigned to each data change. A data > provider > may issue either general or specific data change events, depending > on > circumstances. > > The way I'm reading this, any time that any of the data served up by > the > data provider changes the version gets incremented. Is this correct? > Or are > there extenuating circumstances that affect the version numbering?? > > If the data provider is serving up data based on data changes that > are > coming in via messages, won't the version number be changing a lot? > Thanks, > Leila