[Date Prev][Date Next]
(ITS#5095) back-sql concurrency issues
Full_Name: Pierangelo Masarati
Submission from: (NULL) (184.108.40.206)
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.