[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]