LDAP Accounting

[Phil Mayers]

On 11/12/12 11:31, Kostas Kalevras wrote:

> It's not an abuse but mainly not 'best-practice'. A well configured LDAP

I hate that phrase. No offence, but it's often used as a substitute for 
critical thinking.

*Everything* that is best practice eventually... isn't. And usually, it 
turns out that the "new" best practice was around for ages before anyone 
realised it.

Case in point: RADIUS is used for things which the original designers 
couldn't have anticipated, and for which, arguably, it's not terribly 
well designed. But it *works*.

> server with enough cache memory will be bottlenecked by memory and
> network speed and not by underlying I/O. A frequent writes strategy
> invalidates most of these performance gains since an entry write will
> invalidate entry and database cache entries.

Really? Why?

LDAP doesn't provide MVCC semantics. As far as I can see, an LDAP update 
contains all the information required to update (not invalidate) in-RAM 
cache.

To be clear: I don't use LDAP for data storage. I dislike it's data 
model, and the data typing in particular. But I don't see any reason it 
should be consigned to the "read-mostly" bin on a *theoretical* basis.