OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]