[Date Prev][Date Next]
RE: Trigger registration with backend database!!!
> -----Original Message-----
> From: Kervin L. Pierre [mailto:firstname.lastname@example.org]
> Howard Chu wrote:
> > Good idea. You could write a script for back-perl or back-shell
> to watch the
> You can't do pre-operation plugins with this method. Say I would like
> to reject any modify operations if a certain attribute were changed to a
> certain value, but allow others.
You don't need pre-operation plugins if all you want is change notification.
If you want to filter the pre-operation behavior, write another script and
use back-perl as the front end of your main directory.
> > replog and return the results to you. There is currently no
> explicit control
> > that enables persistent search in OpenLDAP but you can do this
> yourself in
> > how you write your script's search function. back-perl with a
> single global
> > interpreter would be the most efficient approach.
> How so? Say we have 10 simultaneous connections, they all have to wait
> on a single interpreter.
> Please, correct me if I'm wrong on this.
As far as I can tell the only issue is with maintaining global state between
client instances. The only state of interest is the file offset in the
replog at the time the client initiates the persistent search. The only way
to track this is by opening the file once per client; sharing one file
descriptor between multiple clients doesn't work because all the threads
would have the same file pointer. The file descriptor table is already a
globally shared resource, so it makes no difference whether you use a
threaded perl or not. I believe the actual amount of time you spend
executing perl code will be small, and it will be more efficient to manage a
single lock for the this small processing step than to impose the overhead
of multiple thread context switches and initialize thread-specific storage,
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support