[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Transactional ldap


transactional ldap is a unclean defined subject,
but you're talking sense.

> The argument that you need a RDBMS anyway
> when you need transactions doesn't hold in my view.

Thats "argument" is a fairy tale. 

A long time I accept this assertion without substance, but I have changed my mind
and think a little bit different now:
LDAP is very slow in writing data; nobody exspects high write performance.
Nobody should need high performance in this area, because you should add, delete or modify
only little data portions of the DIT (no bulk).
If you have to modify thousands of entries every day a Directory Service isn't good for you.
So why omit transaction in the Directory DB ? 
Why protecting a non-existing feature (write-performance) ?
Directory Services are slow in writing data per definition.
That statement (you have talked about) is pretty inconsistent and illogical.

The antipode is true:
RDBMS must often do write operations. 
RDBMS like MySQL have a good write-performance, so you have to 
weigh up, whether you wanna slow it down with transactions.

High write performance is nice but not required for a Directory Service.
Transactions are always required if you have to deal with relationships.
It's safe to say that relationships exists less in a DIT than in a RDB;
but I can have one critical write operation per week, and exact this operation could kill
my data consistency. 
So if you have a ldbm-backend with transaction support, it's a great convenience in any

> We're using a heavily modified back-ldbm (based on 1.2.11) which supports
> transactions with BDB 3.3.11 and we noted no significant performance drop,
> so we think it's perfectly possible.

1. Have you ever tried to fit your needs via a sql-backend (with stored procedures and so on) ?

2. How can I define a transaction,
is there a specal command into the LDIF file or something else ?
(Where) Can I get a copy of it, and do you have documents about it ?