Berkeley DB Family

I'm running into an instance where simple puts into two databases fail when run in concurrent processes against the RPC server. The clients make heavy use of nested transactions. I may be stressing the limitations of RPC, but the guide does indicate that ACID is supported over RPC.

The failure I receive first is EINVAL(22) from put. This is only seen when two or more concurrent processes are inserting records into the two tables. Here is the psuedo-code:

1) txn_begin (null, &txn1)
2) open_db1 (queue)
3) txn_begin (txn1, &txn2)
4) db1.put()
4.1) txn_begin (txn2, &txn3)
4.2) open_db2 (btree)
4.3) txn_begin (txn3, &txn4)
4.4) db2.put()
4.5) txn4.commit()
4.6) txn3.commit()
5) txn2.commit()
6) txn1.commit()

Note that nested transactions are used here to ensure that the new record and its "associated index" are either added, or jointly fail.

I have factored out creation of dbs in my test code, so DB_CREATE is not passed and I use TXN, LOG, and LOCK inits for the environment.

When this sequence is run in a non-RPC environ, concurrent processes insert as expected. When run against the RPC server, I will see EINVAL (22) returned from (4) or (4.4). The explanation from the server is: "Transaction that opened the DB handle is still active."

I cannot find any evidence of a transaction that is still active or used improperly (ie.overlapped or parent txn access) unless there is txn or db re-use/sharing going on between the client processes and the RPC does not properly distinguish one client process from the other. All "quickfixes" such as manual locks, DB_REGISTER, DB_CDB_ALLDB, etc. are unsupported under RPC. DB_AUTO_COMMIT make no difference since I'm manually enclosing each db open/close in a transaction.

My test runs the above sequence in one open environment for ~1000 iterations and then closes the environment. More than one client process must be run to observe the issue. If I treat the EINVAL as a DB_DEAD_LOCK, it occassionally succeeds on a retry, but on occasion, it will exceed the rety count w/ only 2 running processes. I don't believe EINVAL should be treated like a dead lock.

I would appreciate an assistance in architecting a more robust solution or temporary work-around.

Thanx,

-Tomas