On Thu, 2016-01-14 at 15:07 +0100, Ludwig Krispenz wrote: > On 01/13/2016 11:51 PM, William Brown wrote: > > On Wed, 2016-01-13 at 17:34 -0500, Mark Reynolds wrote: > > > On 01/13/2016 10:01 AM, Ludwig Krispenz wrote: > > > > Ticket 48380 requires that sync repl handles database > > > > reinitializations properly, to be able to determine if cookies > > > > are > > > > presented are valid. > > > > To achieve this plugins need to be able to detcet if the > > > > database > > > > is > > > > imported or restored and this is tarcked in ticket 48402. > > > > > > > > Before implementing a fix, I would like to get feedback on the > > > > design: > > > > http://www.port389.org/docs/389ds/design/detect-startup-after-i > > > > mpor > > > > t-or-restore.html > > > The design looks good to me. I really like the use of the "db > > > event" > > > file(like the guardian file). > > > > I really like the simplicity of this. It's very elegant. > > > > With the startup check for restore and import, why not make both of > > them have the same flag setting mechanism in the backend? Rather > > than > > one setting a global variable and one setting a be flag? > yes, for a plugin it would be simpler to have one function to get > both > states/flags. But I think it is more complicated to set these flags. > The > restore is global and affects all backends, and when the "restore" > file > is detected and the global restore flag is set it would have to set > it > in all backends and the backends are not yet started. > > But I like the idea, maybe we can keep the global restore internal > to > the startup code and have each backend when started check the > "import" > file and check the restore status and then set the BE_FLAGS.
If it affects all backends, this is synonymous with "all backends have the restore flag set". So rather than a global flag, treat the backends indepedantly. This also nets you the neat benefit that say you have backends A, B, C. If you start up the server, after an import, when you run the "post import/ restore" task say on A, it works and you clear the flag. Then it runs on B, and the server has a fault (who knows why but it does). This way the flag is still on B and C. The server would skip A which has already had the import/restore tasks done, and then next start up B and C would recieve the tasks .... I think a global flag is a bad idea. Make it per backend, and a consistent flagging mechanism between import and restore :) -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
signature.asc
Description: This is a digitally signed message part
-- 389-devel mailing list 389-devel@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
