[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] IdAS Update Proposals
|
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/23/07 6:12 PM >>>
>
>Jim, Tom,
>
>I hope I am not being too difficult here. I think that the ability for any applyUpdate operation on any of the interfaces to be atomic depends on the assumptions that are made about the capability of the context provider and the underlying native store.
I agree.
>Not all CPs could support that applying changes to multiple digital subjects. Whether the CP guarantees that all digital subjects and relationships will succeed (atomic) or it is possible for some updates to fail is a capability of the CP. For example, the SAP UME supports batch multiple updates (SPML) where some of the updates could fail. Internally, I support a file based registry that will guarantee atomic updates to multiple subjects.
>I think the same issue may exist at the IDigitalSubject level with multiple attributes, unless I have missed an assumption (and I very well may have). A JNDI provider can assume it can support applyUpdates to a digital subject because JNDI operates at the DS boundary. Is that assumed true for all providers?
It's not even true for all JNDI service providers. In fact, DirContext.modifyAttributes (which is close to IDigitalSubject.applyUpdates) says "Where possible, the modifications are performed atomically.". Meaning, atomicity is not part of the contract.
>If there is a CP that is a virtualization of attributes from multiple sources (e.g. mashup), must this CP support an atomic applyUpdates? A CP for a repository that does not natively have a DS boundary will have the same implementation difficulties at the DS level as the JNDI provider will at the context level.
Right.
So, I agree. I still think we need the API (in order to allow the caller to tell the context provider that he thinks the updates represent a valid state), but I now believe that we should not prescribe atomicity to the operation.
Jim
