Thanks p.. I did some more testing and you are right. It is a RDBMS problem. This is what I found (tested with iSQL and directly on the RDBMS).
In chronological order:
1. SET autocommit=0 2. SELECT @@autocommit -> result: 0, it is turned off
This is standard slapd/back-sql config.
3. SELECT * FROM ldap_entries -> 10 results 4. Now I change the data directly using a different connection and other GUI. I add a record (and commit it). 5. SELECT * FROM ldap_entries -> 10 results
The latter result surprised me. So if data is changed by another connection, it will not be refresh data on other connections.
6. COMMIT 7. SELECT * FROM ldap_entries -> 11 results
So, in order to refresh data, slapd has to prepend every read operation with a COMMIT. This is not logical, is it?
So, I believe adding a configuration option, for people who want to use back-sql with MySQL/InnoDB, could be a handy solution. Where can I add this feature request?
Regards, Frederik
On 07/28/2010 03:01 PM, masarati@aero.polimi.it wrote:
Problem solved. I had to comment a line in sql_wrap.c:
/*
- TimesTen : Turn off autocommit. We must explicitly
- commit any transactions.
*/ SQLSetConnectOption( *dbhp, SQL_AUTOCOMMIT, SQL_AUTOCOMMIT_OFF );
This last line actually prevents slapd from updating resultsets (which are committed) in InnoDB.
I believe this is not correct; we need autocommit to be off since operations that need a commit explicitly do it. I think the problem is in the RDBMS you're using, since other RDBMSes always worked as intended.
Perhaps autocommit should be enabled by default, but the user should be able to disable it through a configuration option in slapd.conf. Should I file a request or bug for this?
Feel free. Configuration options that improve interoperation are always welcome, pending my comment above.
p.