For instance holding an open transaction and trying to get another one during election (where the environment is locked).This indicates that you are using HA / Replication. Most likely Replication Manager (repmgr) in BDB. During an election, actually after an election is completed, if the role needs to be changed (master -> client, client -> master), repmgr will lock-out the environment. Repmgr also locks-out the environment when there is a a major system change (recovery, internal init or role change). When locking-out the environment BDB will wait for existing active transactions to complete (completing a transaction means committing or aborting it). While BDB waits for these active transactions to be completed/resolved, new transactions cannot be started (the lockout prevents new transactions and cursors from starting, until all existing active transactions and cursors have been resolved / completed).
Is it right to say that the best way to use transactions is to hold one each time for all DBs within environment?This sounds like bad design, specifically because I doubt the operations that the transaction should perform atomically are all affecting all the databases in the environment. Doing things this way certainly is a way of degrading performance.
Does multithread like described above can harm that?
Can nested transactions be a solution approach here? If so how?Nested / child transactions are explained here: