[ 
https://issues.apache.org/jira/browse/DIRSERVER-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721720#action_12721720
 ] 

Emmanuel Lecharny commented on DIRSERVER-1377:
----------------------------------------------

After a bit of code browsing, it's not exactly simple to fix.

An index contains tuple<Key, value>. The value can be unique or we can have 
more than one, and in this case, it will be stored into a AvlTree<value> or 
BTree<value>.

The Key  can be anything in :
- Long
- StringValue
- BinaryValue
- DN
- RDN (soon)

The value can be anything,  in two categories.
* Simple types : 
- Long
- StringValue
- BinaryValue
- DN
- RDN (soon)
* Composite types
- AvlTree<Simpletype>
- BTree<SimpleType>

We have to design a de/ser which handle all those cases.

The revert index is working in the opposite way : tuple<Value, Key> but in 
fact, if you forget about what is the key, and what is the value, it's exactly 
the same as a forward index : the Value will be the key and the kay the value 
(and it can also be a composite type.

For instance, if we consider the ObjectClass index, we have :

forward :
<'top', [1,2,3]>
<'person', [1,2]>
<'inetOrgPerson', 1>
<'organizationalUnit', 3>

reverse :
<1, ['top', 'person', 'inetOrgPerson']>
<2, ['top', 'person']>
<3, ['top', 'organizationalUnit']>

All the serialization and deserialization *must* be done in JDBM, not before, 
otherwise we might have some inconsistency.

> Potential concurrency issue when adding/modifying/deleting entries at a high 
> rate
> ---------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1377
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1377
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.5.4
>            Reporter: Emmanuel Lecharny
>            Priority: Blocker
>             Fix For: 1.5.5
>
>
> When adding/deleting entries with many clients (a client add and delete an 
> entry many times), we may have some concurrency problem, as the index are 
> updated without concurrent acces protection.
> Synchronizing the classes where we update the index might help.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to