directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [Schema refactoring] One step further
Date Wed, 21 Oct 2009 00:34:53 GMT
Sorry for having been mute for the past few days, I was busy doing some 
documentatiuon for a client of mine... No fun :/

Here is where I'm doing atm :
- defining a SchemaManager class which will expose a set of methods to 
load schemas and schemaObjects
- implementing it for the most common cases
- using it in the server

This is not really fast, as it leads to a lot of redefinitions, but once 
started, it won't be too complicated.

In the mean time, there are a few points that need to be discussed. 
First of all, we should not anymore access the internal registries 
(AttributeType registry, etc) directly, but using the SchemaManager to 
do so. The idea is to protect them from concurrent access.

So all the places in the server where we were getting a ref to these 
internal registries must now use the SchemaManager instead. (It should 
not be a big deal).

Another point is that the SchemaManager will also be relative to a 
naming context? Right now, the only supported NamingContext will be the 
RootDSE. However, in the future, its hould be easy to define more than 
one SchemaManager and use them.

Last, not least, any modification on the Registries will be done on a 
clone (the clone methods have already been committed), and if the 
Registries are still consistent, then the Registries will be swapped. 
That will protect them from a concurrent access (we will use the 
volatile keyword for that purpose). That also means we don't use 
ConcurrentHashMap for stored data in the intenal registries°;

More code to come in the next few days...

cordialement, regards,
Emmanuel LĂ©charny

View raw message