SchemaUpdate implementatoin

[Andrew Bartlett]

On Fri, 2009-10-23 at 21:16 +0300, Kamen Mazdrashki wrote:
> Hi guys,
> 
> Could you please look at schema_init.c: dsdb_create_prefix_mapping() function.
> As far I understand an existence of such a function, it is to make sure,
> that if someone else modifies prefixMap during our schema update
> operation, then we will update prefixMap cache also (in resume).
> 
> First of all, it seems there is a bug - right after 
> dsdb_find_prefix_for_oid() call, if prefix entry for 'full_oid' already
> exists, then we just return SUCCESS. I.e. prefixMap cache does not
> get updated.

I think it's more that we don't want to overwrite a mapping already
created by another process. 

> But this is not the problem I see with this function.
> Please correct me if I am wrong, but if we are expecting for Schema
> to be modified outside our control (i.e. outside current instance
> we are running in), then we should have a mechanism similar to a 
> critical section on LDB operations during this function execution time.
> IMHO, current implementation is more damaging that useful as it just
> hides a flaw and make it more difficult to reproduce. 
> I mean that it is still possible to corrupt data if Schema is updated
> right after the call to dsdb_read_prefixes_from_ldb() and before
> the call to dsdb_write_prefixes_from_schema_to_ldb() - in this case
> prefixMap is silently overridden in LDB on disk.
> 
> Thus, what is the original intention with this function?
> And if we are to support schema modifications from external source,
> then we are to reload all the Schema Cache (SchemaUpdateNow is the analog 
> for MS AD)?
> Are there any plans for SchemaUpdateNow you've already discussed?

Not really :-).  It's never really been implemented properly (as you
have noticed), with the current implementation being 'just enough' to
get us to pass some tests when things go exactly right. 

> If there were no discussion in this direction, then I would like to suggest 
> following approach:
> - implement periodic service to send SchemaUpdateNow

As long as this only fires if there has actually been an update, that
seems reasonable. 

> - implement schemaUpdateNow() functionality to reload the whole 
>   Schema cache
> - when schema is modified, we may save last-modify-time somewhere, so that
>   all parties interested in schema modification to check if their in-memory
>   Cache is obsolete. If Cache is obsolete, then -> schemaUpdateNow() :)
> 
> Another approach is to keep current implementation and just 'lock' Schema 
> partition for modifications during SchemaReload (dsdb_create_prefix_mapping()
> should be extended to reload whole schema cache also). 
> I am afraid though, that this approach may be hard to implement as we
> need to find out and define very clearly "when schema is to be reloaded".

I think the 'locking' is already in place due to the transactions code,
but much of what you discuss above still needs to be done. 

Currently we fail the schemaUpdateNow test, and I think much of what you
discuss above is needed in any solution. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091026/0cc0d90f/attachment.pgp>