On 12/15/11 5:04 PM, Selcuk AYA wrote:
On Thu, Dec 15, 2011 at 2:27 PM, Emmanuel Lecharny<[email protected]> 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 );
...
txnManager.commitTransaction();
(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.
Ok.
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.
Ok.
Thanks for the heads up !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
