A thread of discussion on the subject of LDAP and referential integrity has surfaced this week. It started with James McGovern :
I also asked the question on How come there is no innovation in LDAP and was curious why no one is working towards standards that will allow for integration with XACML and SPML. I would be happy if OpenDS or OpenLDAP communitities figured out more basic things like incorporating referential integrity.
Pat Patterson pointed out that OpenDS and OpenLDAP have support for referential integrity and so has Sun Directory Server for the last decade:
For some reason, James has a bee in his bonnet over referential integrity and LDAP. I’m really not sure where he’s coming from here – both OpenDS and OpenLDAP offer referential integrity (OpenDS ref int doc, OpenLDAP ref int doc), and Sun Directory Server has offered it for years (Sun Directory Server ref int doc). Does this answer your question, James, or am I missing something?
Bavo De Ridder thinks that the so-called referential integrity is not integrity <>:
So it seems that Sun Directory Service let’s you delete a user but it promises to make sure that it will do it’s very best to delete any references to this user within a “update interval”.
This is partially true. Sun Directory Server can be configured to run the referential integrity processing immediately, in the same thread as the original delete operation. This still occurs as a post-operation plug-in, i.e. after the result was returned to the client application.
It does not mention what a read after the deletion but before the plug-in kicks in will see. Will it still see the user as a member in a group although the user is deleted? I am pretty sure it does. This is of course, at least for me, enough prove that this functionality does not offer referential integrity. At best it offers some kind of deferred cascading deletes (or updates) with no semantics for reads done during the time interval between the original operation and this cascaded deletes and updates.
True. It does.
And I think we can argue on the notion of "referential integrity". It is true that this kind of server does not offer "transactional referential integrity" but it does the self tidying that removes dangling references and it helps and simplifies applications. Also, it is worth mentioning that if an LDAP application had to do the referential integrity itself (i.e. removing dangling references), it could not do it in a single transaction as there is no transaction mechanism in the LDAP protocol.
and he ask for an answer :
To Sun (and any other LDAP implementator): what would the impact be on read/write performance in LDAP if they would implement full referential integrity?
Maintaining full consistent referential integrity would definitely have some read/write performance impact, as a single delete could cause updates to thousands of entries, possibly in other branches of the Directory Information Tree. The LDAP operations usually apply on a single entry and all servers respect the ACID properties for those. There are very few LDAP operations that are applicable to multiple entries : the ModDN operation, the SubTree Delete Control… Those operations have not been implemented in all servers and if they are, they all contain some constraints and limitations because of the possible performance impact they can have on the server.
It’s worth noting that Directory Services are by nature distributed services and most of servers also support a loose consistency replication model. So supporting a full referential integrity would first require to support a full distributed transaction mechanism both in the LDAP protocol and the directory servers. As of today, no directory server has support for transactions, but it’s on the roadmap for the OpenDS project, and investigation has already been started.
We can expect to have the full referential integrity future release of OpenDS, and then we will really be able to measure the performance cost.
Meanwhile, Sun customers are quite happy with the current referential integrity service that matches their expectations.
Technorati Tags: blog, ldap, opends, performance