Monday February 12, 2007
Monday February 12, 2007 LDAP, Transactions, and OpenDS
A few days ago, Trey (who, by the way, is doing a tremendous job in his new role as the OpenDS community liaison) wrote about LDAP directory servers versus relational databases. He neglected to mention one of my favorite benefits, which is the standardized protocol (which means that you don't have to rewrite your applications or at the very least change drivers if you switch from one server implementation to another, and you don't really have to worry about what exactly "varchar" means in the particular flavor you're using). But ignoring that, some of the comments were interesting. In this post, I want to focus on the ones regarding the ACID properties of the protocol and the server.First, I do think that it's important to point out that both the Sun Java System Directory Server (through the Berkeley DB) and OpenDS (through the Berkeley DB Java Edition) use an underlying data store that fully supports ACID semantics, and we do make extensive use of transactions when interacting with it. In particular, any time that you need to perform a write operation the server will need to update multiple databases (in particular, the main id2entry DB and any associated indexes), and that is protected with a transaction to ensure that they will all be updated together as a single atomic unit, or if some problem occurs that none of them get updated. We also rely on the transactional nature for recovery in the event that the server isn't stopped gracefully (e.g., if the server should happen to crash or get forcefully killed, or if there's a hardware failure or underlying system crash) so that it comes back to a consistent state. The Directory Server is able to operate in a fully ACID-compliant manner so that any acknowledged change will be guaranteed on stable storage before returning the result to the client (although administrators can also configure the server to relax these restrictions if they can accept the trade-offs for better performance).
However, when most people are talking about the ACID-compliant nature (or potential lack thereof) of LDAP directories, they probably aren't talking about the underlying data store. They're talking about what is exposed through LDAP itself. It's true that the core protocol specification doesn't have much in the way of atomicity other than to say that multiple changes included in a single modification should all be applied atomically. However, there are a number of extensions to the protocol that can provide various forms of atomicity. They include:
-
Modify DN Operation -- In its simplest form, this operation simply changes the RDN of a leaf entry. However, it also provides the ability to move the entry below a new parent, and it doesn't necessarily need to be performed on a leaf entry. In fact, the modify DN operation can be used to rename an entire subtree (in which case all entries in that subtree will be renamed as a single atomic unit), although we do recommend that it be restricted to small subtrees to avoid locking huge portions of the tree while the operation is in progress. This capability is currently available in OpenDS, and will also be available in the imminent release of the Sun Java System Directory Server 6.0.
-
Subtree Delete Operation -- draft-armijo-ldap-treedelete defines a control which can be used to delete an entire subtree of entries as a single atomic operation. OpenDS currently supports this capability.
-
LDAP Increment Modify Extension -- RFC 4525 defines a new "increment" attribute modification type which can be used to atomically increment or decrement the integer value of an attribute, without the need to know its current value. This can be particularly useful in conjunction with the LDAP read entry controls as described below. OpenDS currently supports this capability.
-
LDAP Read Entry Controls -- RFC 4527 defines a pair of controls which can be used to atomically retrieve an entry as it appeared either immediately before or immediately after applying some change. This can be used to obtain an atomic "set and check" type of behavior, especially when combined with the increment extension. OpenDS currently supports this capability.
-
LDAP Assertion Control -- RFC 4528 defines a control which can be used to perform an operation only if a given assertion is satisfied. This can be used to obtain an atomic "check and set" type of behavior. OpenDS currently supports this capability.
-
LDAP Transactions -- draft-zeilenga-ldap-txn defines a set of extended operations and controls that can be used to perform multiple write operations as a single atomic entity. This draft currently isn't quite far enough along yet to have official OIDs assigned for these components, but we do intend to provide support for it in OpenDS.
Posted by cn_equals_directory_manager ( Feb 12 2007, 10:32:26 PM CST ) Permalink Comments [3]
Post a Comment:
Comments are closed for this entry.
| Archives | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Language | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Links | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Referrers | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Today's Page Hits: 298 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Posted by nate moser on February 14, 2007 at 12:37 PM CST #
Checks like "if (dirtype == ACTIVE_DIRECTORY) ..." are generally a very bad idea. The set of features supported by a directory type can change over time, and in some cases you can't even do a simple version check because features may be backported. It also doesn't work well for directories that you don't explicitly code to handle, and it puts far too much onus on the developer to know all of the quirks of each directory implementation.
Fortunately, though, there is a standard way of determining the capabilities that a given server supports. This is exposed through attributes like supportedControls, supportedExtensions, and supportedFeatures in the root DSE. If you're wondering whether a particular server supports a given control, then just check for the OID of that control in the supportedControls attribute.
Also, note that the feature you mentioned about automatically cleaning up groups when a user is deleted (or renamed with a modify DN operation) is handled by referential integrity and clients generally shouldn't worry about that. Certainly the Sun Java System Directory Server supports this capability, and most other implementations do as well.
Posted by Neil A. Wilson on February 14, 2007 at 10:57 PM CST #
Posted by Neil A. Wilson on February 14, 2007 at 11:03 PM CST #