[Date Prev][Date Next]
Re: back-sql caching
- To: Echedey Lorenzo <firstname.lastname@example.org>
- Subject: Re: back-sql caching
- From: Frederik Bosch <email@example.com>
- Date: Fri, 23 Jul 2010 19:51:15 +0200
- Cc: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9Ff6snGqMGGbB+bqAQFht7MOz84jTlEZSSfs3bc1wiI=; b=aK7WpQpQTrC+gme+pq65dKTFdzjLe5om4Cs6VtrdCys3aaaExcn1be7OespSAOoRtQ Ve3sTydo6klTgPyM0OylPStX+PVVGqiBnZHjHb0CAyq68sTSClDyAI459etjLW1MDJqd hOiXMUNhEPs7YH80tRBHUyH1qzQt+DVTPaJ5o=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pmSnG5svKk3L1OGCGuf31Obz6xfTpoTsYcugbxWESiDazF62KCaWG+sRAW2YAci5lg 0/n02fTGUO/AKpq7DikUSwA4g4OIHJS6HIFfq2a1oPFa3YyFYoRZ/nwJ2EQS+LQKHEBY 26X1R1/7ySNp1xLrOjTU+FOjr/ClW5AEVhNVo=
- In-reply-to: <AANLkTikPw2uRgFLsZPAZ1BBP-fWkEBi2ZB7aHTdOMJOq@mail.gmail.com>
- References: <4C442459.email@example.com> <AANLkTikPw2uRgFLsZPAZ1BBP-fWkEBi2ZB7aHTdOMJOq@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206pre) Gecko/20100626 Shredder/3.0.6pre
Hey Echedey, and others,
You kinda pointed me in the right direction. I discovered what the
problem is: the MySQL engine. Second question. How to solve it.
When I converted the engine of the database (duplicated it first) from
InnoDB to MyISAM, data modifications are recognized by slapd. However,
converting to MyISAM is not an option since I will have to drop all my
foreign keys in that case.
How can I make things work with InnoDB?
On 07/19/2010 12:22 PM, Echedey Lorenzo wrote:
Could you try a commit; after each SQL statement?
2010/7/19 Frederik Bosch <firstname.lastname@example.org
With BackSQL I am trying to make my SQL data available for LDAP
purposes. Setup went OK, server starts and my data is available. I
have one problem. Modifications in the SQL data do not seem to be
executed until I restart slapd. As if the SQL data is cached.
My setup uses openldap_2.4.11-1+lenny1 which I recompiled using
debuild to enable backsql. My sqlserver is MySQL 5.0.5.
So, starting slapd won't generate any errors or problems. When I
delete or modify a row - with an other interface (directly accessing
the SQL server) then LDAP - slapd does not seem to notify the
changes. By enabling query logging for MySQL I found out that it
actually executes a new SQL statement. So the problem seems to take
place when the resultset is processed.
Inserting a new row to ldap_entries gives exactly the same problem.
It is not found until the slapd is restarted. When I started slapd
with -d 16383 I found the line <==backsql_oc_get_candidates(): 0
which confirms my problem in this case.
Annoyingly, restarting the server solves the problem (temporarily).
The data modifications are found and the correct tree is available.
In order to maintain correct data I could restart slapd each 5
minutes, but I think such a solution should be avoided in any case.
Does anyone have a suggestion what could be wrong with my setup?
Thanks in advance.
| Echedey Lorenzo Arencibia |