Difference between revisions of "Stateless Queries"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 2: | Line 2: | ||
{{INM Approval|20060915|Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". (Rene/Mark, 13-0-1)}} | {{INM Approval|20060915|Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". (Rene/Mark, 13-0-1)}} | ||
| − | HL7 Sweden has brought forward a use-case for a query which is stateless on the server. The current query mechanism is based on the fact that it is assumed that the receiving application maintains the state of the result set. A query continuation message (part of the [[Query Transmission Pattern]]) need not contain more than the queryID, the responding system needs to derive everything from that ID. | + | Torbjorn, a member of HL7 Sweden has brought forward a use-case for a query which is stateless on the server. The current query mechanism is based on the fact that it is assumed that the receiving application maintains the state of the result set. A query continuation message (part of the [[Query Transmission Pattern]]) need not contain more than the queryID, the responding system needs to derive everything from that ID. |
The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration. | The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration. | ||
Latest revision as of 15:53, 6 October 2006
This page documents an INM Finalized Workitem, i.e. an issue within scope of the INM Committee that has been finalized, and which (if applicable) has been included in an INM ballot.
Torbjorn, a member of HL7 Sweden has brought forward a use-case for a query which is stateless on the server. The current query mechanism is based on the fact that it is assumed that the receiving application maintains the state of the result set. A query continuation message (part of the Query Transmission Pattern) need not contain more than the queryID, the responding system needs to derive everything from that ID.
The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration.
Possible solution: Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". This allows the server to send back a continuationToken containing the continuation state (which those that brought the use case forward envision to be the relational database id of the last "record" returned). A stateless server could then conceptually add this id to the selection conditions. The attribute would be conditional in queryContinuation: if a responding system values querAck.continuationToken, a querying system SHALL populate queryContinuation.continuationToken with that value.
See Harmonization: add continuationToken to queryAck and queryContinuation
Discussion
- You, obviously, assume responsibility for the declaring in your query conformance statement that the resulting scans might suffer the problem that Lloyd points out: that continuation cookies may result in scans with incomplete or inconsistent data. A continuation query acts on a different (updated) dataset than the original query.
When I think of it an implementation could stuff an "initial query timestamp" in the continuationToken sent to the client. When processing continuation requests the server could return results as if the query had been processed at the initial query time. A common requirement for new systems (at least here in Sweden) is that it should be possible to ask queries like "give me the patients 'current medication list' as it looked on the 1st of august 2006 at 10.30 am". If this requirement is fulfilled it would be possible to guarantee that you would receive exactly the same set of records regardless of if you fetched them all at once or if you used a stateless server and requested a record a day. (Torbjorn Dahlin)
