Hello Armin, thank you for your amazingly quick answer.
> -----Original Message----- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > > in our application there are (collection) fields > > for which we sometimes want to use proxies and sometimes > > not. > > I have noticed the MetaDataManager.setEnablePerThreadChanges(). > > I do the following during initialization > > MetadataManager.getInstance().setEnablePerThreadChanges(true); > > > correct! > > > and every time I want to use different settings than > > the default ones, then I do > > > > --------- > > // modify the MetaDataManager to globally > > // use a different RepositoryDescriptor > > MetaDataManager.getInstance().setDescriptor(MY_TEMP_DESCRIPTOR); > > PersistenceBroker pb > > = PersistenceBrokerFactory.defaultPersistenceBroker(); > Shouldn't be necessary. refresh()-method is automatically > called before a PB instance was obtained from the PB-pool. Yes, I see. I have missed that a call setClosed(false) will not close the PersistenceBroker, but only refresh() it. Strange method name, isn't it? > > > [do all database stuff here ...] > > > > // afterwards, possibly in finally block: > > // reset descriptor in globally > > MetaDataManager.getInstance().setDescriptor(MY_NORMAL_DESCRIPTOR); > > > Not necessary. After using the PB instance with the 'temp repository', > do > PB.close(). If you want to use the 'normal repository' with the same > thread > too do > > MetaDataManager.getInstance().setDescriptor(MY_NORMAL_DESCRIPTOR); > > PersistenceBroker pb > > = PersistenceBrokerFactory.defaultPersistenceBroker(); > after closing the 'temp' instance. Yes, I see that this is an alternative. I dislike to do it that way, because in my application (CORBA client/server), I have no control which thread starts using a PersistenceBroker. Consequently, I should do the setDescriptor(MY_NORMAL_DESCRIPTOR) every time I fetch a PersistenceBroker, and I dislike to do that. > > There are a couple > > of things that I dislike, so if I am right, I would like > > to discuss a different solution with you. > > Great! I like to hear better solutions ;-) o.k., here we go. (1) the current solution maps threads to DescriptorRepositories. That thread-related stuff is always unconvenient for testing and in environments in which you do not fully control these threads. I would prefer to have a mapping from PersistenceBrokers to DescriptorRepositories. (2) the current solution does not offer a convenient API for doing clever mappings. Whenever new stuff is added, such as the addProfile() / loadProfile() methods, this spoils the code even in case only few people need it. What I like so much about OJB is that in other parts of the architecture (SequenceManager, PersistenceBroker, ...) you have an interface that you can implement and configure in OJB.properties. Can't we find a similar way to do that here? For example, I could write my own MetaDataManagerImpl that replaces the existing one. Or I could write my own OllisPersistenceBroker extends PersistenceBrokerImpl and overrides the getDescritorRepostitory() method. (That would work only if that method was used consistently rather than direct access to the field descriptorRepository.) > Do you use the latest from CVS? > There are a new methods > addProfile(Object key, DescriptorRepository repository) > loadProfile(Object key) > make use of that feature easier. oh yes, thank you for that hint. Another, related issue: Why is DescriptorRepository a final class? If it would be an exchangeable implementation of some interface, then you could write an implementation that switches between different repositories. Thomas, if you read this: A few days ago you mentioned in another thread that it would be possible to use OJB without a file such as repository.xml. But the method MetadataManager.init() seems to try to read that file in any case, am I right? Olli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
