Le 4/27/12 6:35 PM, Selcuk AYA a écrit :
On Fri, Apr 27, 2012 at 9:08 AM, Emmanuel Lécharny<[email protected]> wrote:
We don't really care if that serialize the modifications, because the server
does not have to be fast when we inject data, only when we read data. At
least, we could think about a serialization over the operations on one index
like the RdnIndex (as an entry modification may update more than one entry
in this index).
Is that a problem ?
Depends. What I have been describing in the emails and trying to
implement is an optimistic locking scheme where modifications can go
in parallel unless they conflict. It seems we could just get a big
lock for write txns rather than dealing with optimistic concurrency
control.
Ok, I see.
What would be the impact on the txn branch if we fallback to such a
system ?
What also would be the impact on the current code, assuming that we
update many elements on the RdnIndex, so that the optimistic locking
scheme keeps working ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
