Issue 5095 - back-sql concurrency issues
Summary: back-sql concurrency issues
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
: 5199 (view as issue list)
Depends on:
Blocks:
 
Reported: 2007-08-19 16:57 UTC by ando@openldap.org
Modified: 2020-03-18 20:36 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ando@openldap.org 2007-08-19 16:57:42 UTC
Full_Name: Pierangelo Masarati
Version: HEAD/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


I believe there are (at least) two issues with back-sql:

1) cached db handle AVL access in backsql_get_db_conn() is not protected by
mutex, as insertion/deletion.

2) cached db handles are shared by operations performed by the same client
connection, so concurrent operations use the same db handle.  I believe each
write operation should use a separate handle in order to be atomic.

Issue (1) will be fixed shortly; issue (2) will be fixed as soon as I finish
rewriting db handle code.  In this sense I think it's meaningless to share
handles for write operations based on the client connection.  All in all, the
same user is always used to access the DB, and access control is done by the
backend, while there's no guarantee the client will serialize requests.  So a
separate pool of handles could be maintained and used for write operations only;
handles wouldn't need to be created all times, they can be reused.  Only, they
need to be used exclusively by one operation, so that SQLTransact() is only
called for the specified sequence of operations.  The pool could be fixed size,
deferring operations when busy, or grow on request.

p.

Comment 1 ando@openldap.org 2007-08-19 18:31:07 UTC
changed notes
moved from Incoming to Software Bugs
Comment 2 ando@openldap.org 2007-08-19 22:28:44 UTC
ando@sys-net.it wrote:
> In this sense I think it's meaningless to share
> handles for write operations based on the client connection.  All in all, the
> same user is always used to access the DB, and access control is done by the
> backend, while there's no guarantee the client will serialize requests.  So a
> separate pool of handles could be maintained and used for write operations only;
> handles wouldn't need to be created all times, they can be reused.  Only, they
> need to be used exclusively by one operation, so that SQLTransact() is only
> called for the specified sequence of operations.  The pool could be fixed size,
> deferring operations when busy, or grow on request.

Actually, there's no need to cache handles based on the connection or
so.  It's better to have connections cached per-thread, to make sure
they can only be used one at a time.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------


Comment 3 ando@openldap.org 2007-08-20 12:38:29 UTC
changed notes
Comment 4 ando@openldap.org 2007-08-22 21:42:56 UTC
changed notes
changed state Open to Release
Comment 5 ando@openldap.org 2007-08-22 21:50:21 UTC
changed notes
Comment 6 Howard Chu 2007-11-01 14:34:28 UTC
changed notes
changed state Release to Closed
Comment 7 Howard Chu 2009-02-17 05:21:53 UTC
moved from Software Bugs to Archive.Software Bugs
Comment 8 OpenLDAP project 2014-08-01 21:06:48 UTC
back-sql
fixed in re23
reworked in HEAD
Comment 9 Quanah Gibson-Mount 2020-03-18 20:36:33 UTC
*** Issue 5199 has been marked as a duplicate of this issue. ***