RE: dynamically switch RepositoryDescriptor (setEnablePerThreadCh anges)

[ol...@ppi.de]

Hello Armin,

thank you for your amazingly quick answer.

> -----Original Message-----
> From: Armin Waibel [mailto:armin@code-au-lait.de]

> > 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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: dynamically switch RepositoryDescriptor (setEnablePerThreadChanges)

[Armin Waibel <ar...@code-au-lait.de>]

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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org