[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-397?pag...
]
Manik Surtani commented on HSEARCH-397:
---------------------------------------
Well the problem with swapping the SearchFactoryImpl is that you would need to stop all
threads working on the old one while the ref is swapped. And this is an unnecessary
synchronization point.
What I was thinking of was more along the lines of making the internal configuration
objects mutable and exposing a safe way to export these objects. E.g., if all
configuration pertaining to a class type can be encapsulated in a single object, e.g.,
class ClassConfiguration {
DocumentIndexBuilder db;
DirectoryProvider dp;
// etc
}
and we maintain a ConcurrentMap<Class, ClassConfiguration> which is looked up
whenever you need to index anything.
The ConcurrentMap could be constructed during SearchFactoryImpl construction, and any
classes passed in to the SFI constructor can be used to initialize this map. Or this map
would start empty if no classes are passed in. Lets call this map classConfigMap
Then, on initForClass(Class c), the SFI would do:
0. if c not in classConfigMap:
1. Create ClassConfiguration.
2. init the DocumentIndexBuilder and add this to the ClassConfiguration
3. acquire a directoryInit lock // to ensure the same directory location isn't
concurrently initialized
4. init DirectoryProvider and add to ClassConfiguration
5. Release directoryInit lock
6. classConfigMap.putIfAbsent(class, classConfig);
Allow classes to be lazily added to the configuration
-----------------------------------------------------
Key: HSEARCH-397
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-397
Project: Hibernate Search
Issue Type: New Feature
Components: engine
Reporter: Emmanuel Bernard
Assignee: Sanne Grinovero
Fix For: 3.3.0
Assigning Sanne to pick his interest ;)
Infinispan needs a way to add new classes lazily, ie after the SearchFactory
initialization. Today's initialization cannot ensure that because we assume a single
thread inits everything before freezing the state and then support multiple thread.
We need to explore the idea of making the configuration mutable but not suffering too
much of the thread-safety implications.
We also should allow to remove a class from the configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira