SchemaUpdate implementatoin

[Kamen Mazdrashki]

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.

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?

If there were no discussion in this direction, then I would like to suggest 
following approach:
- implement periodic service to send SchemaUpdateNow
- 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".



BR,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/