[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] modify subscription request...
Gerry, Let me try to explain this again. Given the same contact list example. Lets assume that the contact list has values A, B, and C. Now assume that two RAs are going to update the list at different times with different changes (i.e. the requests are no concurrent). In the current SPML proposal, the events would be: 1) RA 1 adds contact D using a modify request 2) The modify request is finished, the contact list now contains A, B, C, and D 3) RA 2 removes contact B using a modify request 4) The modify request is finished, the contact list now contains A, C, and D Now in your current proposal the events would be: 1) RA 1 adds contact D using a modify request that updates the list to be A, B, C, and D 2) The modify request is finished, the contact list now contains A, B, C, and D 3) RA 2 removes contact B using a modify request that updates the list to be A, C 4) The modify request is finished, the contact list now contains A, C Now in the current SPML specification, the correct result is obtained in step 4. In you current proposal, the incorrect result is obtained in step 4. In this example there are no concurrency issues, no transactions issues, and no errors will be reported. Each request unto itself is correct, but the result is corruption of data. This is caused by the way your current proposal handles modifications. It simply won't work. it won't work in this simple case and it won't in a more complex one. The current specification will work fine in this example. Jeff B. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wed 3/12/2003 4:28 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] modify subscription request... Jeff, I apologise if I misinterpreted the question but I'm still not seeing where I'm going wrong. I've been approaching the problem as you suggest, that these are long term "transactions", or maybe I should say sequences of operations. If you try to modify a value in an entry or attribute that has been deleted the current SPML should raise an exception, right? If you're saying that two clients must be able to simultaneously delete a value then neither of us suffer from a problem there beyond that a noSuchObject type error will occur for the second attempt. If data corruption is your concern then I'm not sure that I see the difference between approaches when one client is modifying a value/attribute while another is trying to modify the same value/attribute. The end result is that one will fail or the state of the entry will reflect the result of the winner (or loser) of the race, even though each is atomic. I'm not suggesting that normalising the data data fixes the problem, I'm saying that the problem exists in both approaches. The more I think about it, isn't there another problem? If you are saying that to change a contact, since you don't have the ability to simply replace a single value, your implementation would send a value delete folowed by a value add modification then there is another opportunity between those two operations for a problem. Maybe you could be more explicit in telling me exactly how you have solved this? Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/12/2003 11:17 | | | AM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] modify subscription request... | | | >------------------------------------------------------------------------------------------------------------------------------| Gerry, The example I was using was to delete an element from a sequence. This has nothing to do with concurrence or record locking. Assume the two requests happen a day apart and the problem still exists. In the current SPML specification the example would be equivalent to sending a modification request listing the value with the operation delete. This would not delete the entry (that would require a delete request). I do not believe that an error should be returned since the end result is the as if the value existed and was removed. Your current proposal will result in data corruption if not used with transactions. Even with transactions, you would need to have data synchronization as part of every modification request. Normalizing the data does not solve this problem either. I do not mean to imply I want transactions in SPML. I do not. I want a solution that solves this problem without transactions. We currently have that. The current SPML specification does not suffer from this problem. If you believe that it does, send me an example. Again, to be perfectly clear, I am not taking about deleting an entry, I am talking about removing a value from an entry. As you say, the only solution to this problem without transactions is to have the ability to update parts of a subscription on a modification request. As you indicated, to do that you would have to have some kind of XPath to identify what you are updating, the operation (add data, replace data, delete data), and the data you are adding, replacing, and deleting. Is that what you are proposing? If so I would like to see some examples of how this would work. These issues should not be ignored simply because we are running out time. It is precisely because we are running out of time that we should discuss them now rather than waiting until after we have made a decision. We should know as much about what we are deciding as possible. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, March 12, 2003 1:19 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] modify subscription request... Jeff, Are we getting into a semantic argument again? Perhaps I should have just called it record locking. I think I understand the problem and we can use whatever term you prefer but the problem exists in either solution. Your trivial example in the current proposal completely, and deliberately, ignores the issue. An error will be reported even in your simplistic example and if SPML does not then it should. LDAP certainly will report a noSuchObject if an RA 3 has gone in between the two modifies and deleted the entry. In any real life situation, a modification is rarely made based on some sort of divine inspiration that dictates that the lastname must now be "smith" rgardless of its previous or current state. There will be a read/modify cycle and argue as you might that introduces a race condition. I think you've been more vocal in suggesting transactions than me: ("1) There is the need for transactions (i.e. all operations in a batch must succeed or they all roll back)", Monday february 24). I have, I thought, made my position clear on the use of standards outside the scope of this committee. The issue of what is required on a modify is a very good point. This comes down to where the schema validation is performed and the ability to express detailed changes. My proposal is less detailed than the LDAP modify message where individual attributes may be added, deleted or replaced. It would definitely be possible to introduce the ability to specify modifications to specific portions of the target data in a modify message using the same XPath model I've used in the query mechanism. Since time is running out, for now, and as I said in my example, it would make sense to normalise the data more than I have so that less state would need to be hauled around. For example, it would probably be common to implement something like you did in your examples where contacts are just string identifiers rather than structures embedded in the data. Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/12/2003 04:42 | | | AM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: provision@lists.oasis-open.org | | Subject: RE: [provision] modify subscription request... | | | >----------------------------------------------------------------------- -------------------------------------------------------| Even transactions would not solve the problem I described. This is not a transaction problem, but rather a stale data problem. Let's look at the friends and family contact list as an example. Assume there are two RA systems access the subscription PSP. If one RA adds a contact, the events would be something like: 1) Start a transaction 2) Update the account with the new list of contacts 3) End the transaction Now the second RA wants to remove one of the previously existing contacts 1) Start a transaction 2) Update the account with the new list of contacts 3) End the transaction There is no race condition. There is no concurrent access. There is simply loss of data. Now you could fix this by making the events: RA 1: 1) Start a transaction 2) Query for the current state of the contacts 3) Figure out the changes to the contact list 4) Update the account with the new list of contacts 5) End the transaction RA 2: 1) Start a transaction 2) Query for the current state of the contacts 3) Figure out the changes to the contact list 4) Update the account with the new list of contacts 5) End the transaction Your current proposal does not include transactions. Do you intend to add that? Also your current proposal does not include a way to query for only the parts of the target that are relevant to calculating the change request (in this case query for the contact list). That is not needed to solve this problem, but would be an improvement. Now in the current SPML specification, the events would be: RA 1: 1) Update the account to add the new contact RA 2: 1) Update the account to remove the unwanted contact (if that contact does not exist, no error is thrown) There is also another related problem to doing updates. If you use the current XSD approach to define sequence cardinality, then that cardinality applies to both add Subscription Requests and modify subscription requests. In other words when you define the basic account as having a first name element defined as: <xsd:element name="firstname" type="xsd:string" minOccurs="1" maxOccurs="1"/> Doesn't this imply that on all modification requests you would have to pass the first name, regardless of whether you where modifying the first name or not? This again introduces the same stale data problem I described earlier, but also raises a more fundamental question: does it make sense to have to redefine all of the required data for an account on every modification requests? Or is it the case that the cardinality definitions only apply to add requests? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, March 12, 2003 12:50 AM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: Re: [provision] modify subscription request... Jeff, I think this is just the price you pay without transactions. Probably the best that I can offer you is that the race condition that you mention could result in a Fault or exception. In my example interfaces I haven't listed faults but I can imagine a "conncurrentAccessFault" or something of that nature to signal this kind of condition. I'm not sure that directory servers can address this problem in any better way. With LDAP/DSML type systems you obviously have the ability to just specify the delete of a single attribute but you would still get a noSuchAttribute error under similar conditions. I have to agree that this is not an academic problem and I've seen some inventive ways of dealing with it. The most common in my experience is the use of timestamps to version the data but I don't think there's any perfect solution. Unless, that is, you have one? Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/11/2003 06:39 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: provision@lists.oasis-open.org | | cc: | | Subject: [provision] modify subscription request... | | | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, Thee is something I have not been able to figure out in your proposal. For subscription targets that contain sequences of elements, how do you send a modify subscription request to remove one of the elements? You can't just resend the whole list because you may not have the current state of the subscription. Even if you queried for the current state of the subscription, another client could change it after you query for it, but before you send the update. To put this in perspective of the Tiny Telecom example, how would the RA web application remove a friends and familiy contact? BTW, this is not an academic question. In many systems that do RBAC, user role membership is often defined as a list roles on a user record (this is often the case for both LDAP and RDBMS based systems). One delegated administrator may grant (add) a role to a user while another revokes (removes) a different role from the same user. How would this type of provisioning operation be supported in you proposal? Jeff Bohren OpenNetwork Technologies ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]