directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
Subject Txn Work Update(2)
Date Wed, 30 Nov 2011 10:48:34 GMT
Hi all,
time to give an update on the txn status. I just checked in some code
with explanation of the changes for each project separately. Here is
just an overall summary and todo:

*I added txn being/commit/abort to ldap requests and ran some test
with txns enabled. Put in various fixes to the txn layer based on the
tests. So first signs life signs for txns. More tests will be done but
I need to digress into AVL first. I also need to handle paged search.

*I have also been working on removing interfaces related to
modification from the partition and have been trying to get rid of the
Store interface. Got rid of the store interface except for config
methods and calls from the ui layer. I removed the modifications up
but still have to call the modification methods of the partition
interface because SchemaPartition triggers some changes based on the
logical  change. I believe those changes can be removed to schema
interceptor? In general, if a partition wants to do a change based on
a data update, then it should be able to do it during master table
update or by registering an interceptor(For example I changed multi
file ldif partition to do file updates when master table is updated).
Then we can get rid of the modification methods on partitions.

Note that, how search is done is still upto the partiton.
DefaultSearchEngine is changed to work with any partition and returns
transactioanally consistent data.( it used to work with Store
interface. Now it works with Partition interface. ). However, a
partition can use another search engine and can use the data in txn
logs to provide consistent data.

* Would be good to get triggers working as they are a nice way to
demonstrate txns. What is the reason trigger tests are ignored?

* Would be good to have statement snapshot isolation for
EntryFilteringCursor. Not having this doesnt affect ldap requests but
might affect code that works with EntryFilteringCursor directly.
Currently there are few cases of this especially during startup.

* Tried to introduce some rules into how modifications are done: If we
think of search engine and data modification layer as a data layer,
then under it we have storage level. Storage level might have a cache
of entries, or index entries or tuples. When a thread reads an object
from the storage layer and wants to update it, another thread might be
reading the same object. To avoid confusing the reader thread, object
to be changed should be cloned before change is applied. Changed
modification layer to follow this rule. As mentioned in the previous
emails, default search engine is modifying index entries and this is
not good, I  put a workaround for this.


regards,
Selcuk

Mime
View raw message