The problem is that every internal (slapi_OP_internal) call must specify the parent transaction when creating a new transaction if it is being called from within a betxn. The problem for plugins and other server code is that it is cumbersome to get and set the transaction handle. Furthermore, if this is not done, the plugin could hang the server if it attempts a non-transacted operation in the middle of a transaction.
The solution is to use a scheme that just works transparently. Thread local storage can store a stack of parent/child transactions per thread.
69c9f3b..a0488ff master -> master
Author: Rich Megginson firstname.lastname@example.org
Date: Fri Feb 17 15:13:39 2012 -0700
Reviewed by: nhosoi (Thanks!)
Fix Description: Create a new thread local storage key in dblayer.c
thread_private_txn_stack. This is used to hold the stack of transactions
in the current thread. A stack is used because there may be nested
transactions. The transaction at the head of the stack is the currently
executing one and the parent to use for new nested transactions. When a
new txn is started, it is pushed on the stack to be the new head. When a
txn is commited or aborted, it is popped off the head of the list, and the
old parent transaction is restored in the pblock. Any db backend top level
function must call dblayer_txn_init() to set its txn handle to the current
transaction, and set SLAPI_TXN in the pblock. The txn functions also allow
the txn to be passed in via the pblock. This approach gives us the
flexibility to support LDAP transactions in the future.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
Added initial screened field value.
Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.11.a1
to comment on this ticket.