Hi Olli, > > > 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? >
PBState#setClosed(true/false) used to indicate the state of the used PB instance and to do cleanup/init stuff. Any alternative method names? > > > > > [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. > You can try to encapsulate this stuff (implement your own PBF, ...). But you are right, this behaviour isn't smart and can be problematic when using OJB within j2ee container, e.g. bean A calls bean B, each bean use PB instances and bean B runs in a different cluster node !?! Which DR does bean B use? > > > 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. > can you explain this more detailed? Sounds like a change of OJB architecture. Do you want to ask DescriptorRepository (DR) for PB instances? or do want to set up a PB pool for each used DR? > > (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. I think (currently) only a few people using this feature. MetadataManager was introduced end of last year, thus it's now in 'beta testing' ;-) > 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. > I agree this can be useful for some special cases. But if we start to make MetadataManager pluggable, why not rework the complete Metadata handling? Listener for metadata events (e.g. add remove FieldDescriptor in ClassDescriptor), better separation of DR and ConnectionRepository, smarter version of RepositoryPersistor, ... > 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? because we do not use a Factory to get new DR instances. Intern OJB use 'new DescriptorRepository' calls, thus it's not possible to use an inherited class, ergo I made it final (to help the compiler ;-)). > 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? > yes, you need an 'empty' repository to start up OJB. see http://db.apache.org/ojb/faq.html When doing the refactoring of the metadata stuff a few month ago, I don't want to change existing behaviour of OJB. But it shouldn't be difficult to make OJB start without any repository file. regards, Armin > Olli > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
