hlaw wrote:
Thanks. I also have a search in the previous discussions and the following is probably the solution to my question.
https://www.openldap.org/lists/openldap-technical/201409/msg00077.html
Quoting from the above -
Before starting any other threads: Create the environment. Open a transaction. Open all DBI handles the app will need. Commit the transaction.
May I confirm my understanding that, after the above steps, each thread created for accessing the database in the same process should :
- Open a transaction in the same environment
- Directly use the persisted DBI handles (saved before creating the
threads) for read / write without calling mdb_dbi_open 3. Commit / abort the transaction,
regardless of whether the DBI handle is used for read / write?
Also, in respect of the initial transaction for opening the DBI handles, is a read-only transaction sufficient even if the database it opened would be written to in subsequent transactions, since the initial transaction itself would not be writing to the database?
That is what "After that use the DBI handles freely among any transactions/threads" means.
Thanks a lot.
- H Law
2015-04-03 2:54 GMT+08:00 Howard Chu <hyc@symas.com mailto:hyc@symas.com>:
hlaw wrote:
Thank you!
It appears that mdb_dbi_open() must be called before any read / write access to a database in a transaction,
True.
and all read / write have to be done in a transaction?
True.
If this is the case, is it correct that due to the concurrency restriction above, there is essentially no concurrent access (including read and write) to the same database in a multi-threaded process,
False.
since a database is available to one transaction in a time?
False. Reread the mdb_dbi_open doc.
http://symas.com/mdb/doc/group__mdb.html#gac08cad5b096925642ca359a6d6f0562a
2015-03-30 19:52 GMT+08:00 Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no mailto:h.b.furuseth@usit.uio.no
<mailto:h.b.furuseth@usit.uio.no mailto:h.b.furuseth@usit.uio.no>>:
You're abusing mdb_dbi_open(). Its doc says: "This function must not be called from multiple concurrent transactions in the same process. A transaction that uses this function must finish (either commit or abort) before any other transaction in the process may use this function." That text could have stood out a bit better in the doc:-( The error is simple for lmdb to try to catch, though without locking it cannot guarantee to catch it. Try this patch: <http://folk.uio.no/hbf/__OpenLDAP/mdb.serial-open.diff <http://folk.uio.no/hbf/OpenLDAP/mdb.serial-open.diff>> (Howard, this is branch "mdb/serial-open" in my UiO repo.) Not sure if it should do more than this. E.g. attack mdb_drop too. Maybe set MDB_TXN_ERROR since a program with broken threading can break the DB. -- Hallvard-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/