<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Times New Roman, Times, serif">Hello,<br>
<br>
</font>
<blockquote><font face="Times New Roman, Times, serif">I was
investigating the alternative/impacts of a new plugin and I
would like to share some thoughts and check I did not miss
something important.<br>
<br>
Here is the description of the problem we want to address. In
MMR topology, we have an entry containing a single valued
attribute. It is an integer syntax attribute. Our need is that
the attribute can only be increased. So if its initial value is
5, an update MOD/REPL '6' is valid and applied, while MOD/REPL
'3' is invalid and rejected/ignored. Also being in MMR, the
attribute can be updated on several instances. <br>
<br>
The current approach is to create a BE_PREOP or BE_TXN_PREOP
plugin. This allow to retrieve the current value from the pblock
(SLAPI_ENTRY_PRE_OP) and guaranties the value is exact as only
one operation is processed at a time.<br>
<br>
The plugin registers a mod operation callback. It controls the
new_value vs current_value to check that new_value
>current_value. The plugin will update the mods. In
particular translates a MOD/REPL into a MOD/DEL(current value) +
MOD/ADD(new_value).<br>
<br>
Regarding the change of the MODS (mod/repl -> mod/del +
mod/add), the plugin should be a BE_PREOP. This is because MODS
are applied after BE_PREOP plugins, then new MODS added by
BE_TXN_PREOP plugins are applied. A BE_TXN_PREOP plugin may
translate mod/repl -> mod/del+mod/add but it is too late,
mod/repl has already been applied after BE_PREOP plugins were
called.<br>
<br>
Regarding replication, for non replicated updates, it should
just reject (unwilling to perform) ops with new_value <
current_value.<br>
For replicated update I see the two cases </font><font
face="Times New Roman, Times, serif">([server / csn / attribute
value] ): </font><font face="Times New Roman, Times, serif">[A/csnA/valueA],
[B/csnB/valueB] and t</font><font face="Times New Roman, Times,
serif">he expected final value is ValueB+csnB</font>
<ol>
<li><font face="Times New Roman, Times, serif">csnA < csnB
and ValueA < ValueB. </font></li>
<ol>
<li><font face="Times New Roman, Times, serif">When server A
receives csnB/valueB, this is fine as ValueB>ValueA.
But to know that ValueB will be selected the plugin needs
to check that csnB>csnA.</font></li>
</ol>
<ol>
<li><font face="Times New Roman, Times, serif">When server B
receives csnA/valueA it has 3 possibilities:</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">reject
(unwilling to perform) the update. But then replication
A->B will fail indefinitely</font></li>
<li><font face="Times New Roman, Times, serif">erase the
update. For example the plugin could erase the mod from
the set of mod. <br>
</font></li>
<li><font face="Times New Roman, Times, serif">let the
operation continue because csnA < csnB, the kept
value will be ValueB. Here again the plugin needs to
check csnA vs csnB</font></li>
</ol>
</ol>
<li><font face="Times New Roman, Times, serif">csnA > csnB
and ValueA < ValueB. <br>
</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">When server A
receives csnB/valueB, this is fine as ValueB>ValueA.
But to know that ValueB will be selected the plugin need
to check that csnB>csnA.</font></li>
<li><font face="Times New Roman, Times, serif">When server B
receives csnA/valueA it has 2 possibilities:</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">reject
(unwilling to perform) the update. But then replication
A->B will fail indefinitely</font></li>
<li><font face="Times New Roman, Times, serif">erase the
update. For example the plugin could erase the mod from
the set of mod. <br>
</font></li>
</ol>
</ol>
</ol>
<font face="Times New Roman, Times, serif">So I think the plugin
should not rely on the new_value present in the operation but
rather computes the final_value (taking into account the CSN).<br>
If the final_value > current_value, it let the operation
going on (even if the new_value in the operation <
current_value). If the final_value < current_value it should
remove the mod from the mods (2.2.2) and likely log a message.<br>
<br>
Changing MOD/REPL into MOD/DEL+ MOD/ADD is a possibility but the
attribute being single valued I think it is not mandatory.<br>
<br>
Thanks<br>
thierry<br>
<br>
<br>
</font></blockquote>
</body>
</html>