directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Txn Work Update(2)
Date Thu, 15 Dec 2011 17:12:36 GMT
On 12/15/11 5:04 PM, Selcuk AYA wrote:
> On Thu, Dec 15, 2011 at 2:27 PM, Emmanuel Lecharny<>  wrote:
>> On 12/15/11 12:25 PM, Selcuk AYA wrote:
>>> Hi all,
>>> update on my status:
>>> * There is going to be a big change in my life soon and I will do a
>>> big move. So I will be MIA for some time( around 2 months) and after
>>> that I will have less time to contribute but I will try to keep being
>>> involved in development and discussions.
>> Ok. I wish this is a move for a better life :)
>>> * I did a recent check in. There are some tests that fail. I will list
>>> them below. The basic reason that those tests are failing is that they
>>> do queries and updates of which  some are transactional, some are not
>>> and this leads to wrong results.
>> I spent some time yesterday on the failing tests. What I need here is a clue
>> about how to make some operation transactionals. If you can update us, that
>> would be great.
> please take a look at ldap protocol handlers.

Ok, got it. It's about doing :

txnManager.beginTransaction( false );

(or txnManager.abortTransaction() if we've got an error)

When should we put a 'true' as a parameter ?

>>> And the basic reason they do queries
>>> and updates in a non transactional way is that I did not put
>>> transaction begin/commif/abort( ie, txn demarcation) at CoreSession.
>>> This is the layer we start the execution of  the basic ldap operations
>>> but I thought there might be clients of CoreSession which want to
>>> group operations together and execute them as a single txn(If you
>>> think this is not necessary, please let me know).
>> I don't think it's anymore necessary. We have refactored all the operations
>> last month so that we never have to re-enter the chain twice when processing
>> an operation.
> I was thinking of clients of CoreSession within ApacheDs. For example,
> revert of changelog or changepassword.

I see. Actually, we get errors when reverting some modification 
operations, so I guess we must add some txns boundaries in the 
processing of reverts.

> There might be other cases.  I
> am not talking about the interceptor chain here. If these kind of
> clients do not need to group ldap operations together as a
> transaction, then move txn begin/commit/abort to CoreSession, and for
> search close the transaction when entry filtering cursor is closed.
> Note that, there is also the case that all over the server, cursors
> are not closed or not closed in a finally clause. I think these should
> be fixed.

Definitively something we have to fix. Reminds me the JNDI 
NamingEnumeration that requires to be closed explicitely :/
>>>   Also, there is at
>>> least search, for which the cursor is kept open above CoreSession, So
>>> for search, the caller has to handle txn commit, abort.Also there
>>> might be some cases where operations do not use session at all.
>> Well, we do some lookups directly on the nexus, as we are inside the chain
>> already, and I guess we are using the ongping transaction here. If it's not
>> the case, then we should probably have a way to make those operations part
>> of the ongoing txn (don't know how difficult it is)
> Operations within interceptor chain is part of the same transaction,
> But we have some cases which do not use sessions and which directly
> interact with nexus outside interceptor chain. For example some
> interceptor initializations.

>>> As a result, I decided to handle each  caller of CoreSession
>>> operations separately and this increased the number changes that had
>>> to be done. I handled ldap protocol handlers and change password.
>>> Right now StockServerSuite is passing except three tests.
>>> StockCoreSuite and MigratedStockCoreSuite is failing. The reason is
>>> they use LDAPCoreConnection and this is not transactional yet.
>> I have some failures in core-integ. Do you have them too ?
> StockCoreSuite and MigratedStockCoreSuite  =>  Yes . These are using
> LdapCoreConnection. If you move txn begin/end to CoreSession you wont
> need to handle LDAPCoreConnection separately.


Thanks for the heads up !

Emmanuel L├ęcharny

View raw message