[JDBM] Why Optimistic Concurrency Control is best for LDAP?

[Alex Karasulu <ak...@apache.org>]

Hi guys,

OCC is the best strategy over all for implementing local transactions so we
can have isolation and atomicity in the server. It's the best strategy for
an LDAP DIB because writes are less frequent in LDAP than reads. Presuming
that multiple transactions can complete in most cases without affecting each
other means OCC is more viable. OCC breaks down when there are more
conflicts with intensive write activity as in relational databases requiring
transactions to rollback. This will not be the case for most of our
deployments.

So as we think about building or finding a better BTree implementation than
JDBM we should consider OCC via MVCC in the BTree implementation itself
since we need isolation and atomicity across indices as well as the master
table.

Just some random thoughts.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: [JDBM] Why Optimistic Concurrency Control is best for LDAP?

[Alex Karasulu <ak...@apache.org>]

On Sat, May 15, 2010 at 2:41 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> On 5/15/10 12:17 PM, Alex Karasulu wrote:
>
>> Hi guys,
>>
>> OCC is the best strategy over all for implementing local transactions so
>> we
>> can have isolation and atomicity in the server. It's the best strategy for
>> an LDAP DIB because writes are less frequent in LDAP than reads. Presuming
>> that multiple transactions can complete in most cases without affecting
>> each
>> other means OCC is more viable. OCC breaks down when there are more
>> conflicts with intensive write activity as in relational databases
>> requiring
>> transactions to rollback. This will not be the case for most of our
>> deployments.
>>
>> So as we think about building or finding a better BTree implementation
>> than
>> JDBM we should consider OCC via MVCC in the BTree implementation itself
>> since we need isolation and atomicity across indices as well as the master
>> table.
>>
>> Just some random thoughts.
>>
>>
> Seems good to me. And easier to implement. Now, what if we decide to
> implement both strategies (in the future) and let the admin decide which one
> to use depending on the usage ? For instance if the writes are not
> negligable compared to the reads, a MVCC system could be usefull.
>
>
If writes are not negligible then you don't want optimistic concurrency
control because then the amount of rollbacks will be inhibitive.  I guess
you mean using a locking strategy if the writes will cause too many
rollbacks. I don't think it's necessary to consider this. If the writes are
causing insane amounts of rollbacks then the user is using the wrong data
store IMHO.


> Sure, it's really prematurate, and we don't even know if we will ever use
> such a system, but that would be great to be able to switch from one system
> to another just by modifying the configuration.
>
>
This is one of the very few places where I think it's not necessary to even
have it as a configuration parameter.


> From now on, I think I will continue to check JDBM and see if we can
> impelment some OCC strategy on top of it, instead of the heavy
> synchronization we have.
>
>
I don't think we can implement something like this "on top of" JDBM, you
have to go into the implementation and modify it. Unfortunately me gut tells
me no matter what we do we're going to have to get our hands dirty here with
the BTree implementation.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: [JDBM] Why Optimistic Concurrency Control is best for LDAP?

[Emmanuel Lecharny <el...@gmail.com>]

On 5/15/10 12:17 PM, Alex Karasulu wrote:
> Hi guys,
>
> OCC is the best strategy over all for implementing local transactions so we
> can have isolation and atomicity in the server. It's the best strategy for
> an LDAP DIB because writes are less frequent in LDAP than reads. Presuming
> that multiple transactions can complete in most cases without affecting each
> other means OCC is more viable. OCC breaks down when there are more
> conflicts with intensive write activity as in relational databases requiring
> transactions to rollback. This will not be the case for most of our
> deployments.
>
> So as we think about building or finding a better BTree implementation than
> JDBM we should consider OCC via MVCC in the BTree implementation itself
> since we need isolation and atomicity across indices as well as the master
> table.
>
> Just some random thoughts.
>    
Seems good to me. And easier to implement. Now, what if we decide to 
implement both strategies (in the future) and let the admin decide which 
one to use depending on the usage ? For instance if the writes are not 
negligable compared to the reads, a MVCC system could be usefull.

Sure, it's really prematurate, and we don't even know if we will ever 
use such a system, but that would be great to be able to switch from one 
system to another just by modifying the configuration.

 From now on, I think I will continue to check JDBM and see if we can 
impelment some OCC strategy on top of it, instead of the heavy 
synchronization we have.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com