You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by "Janssen, Roger" <Ro...@ibanx.nl> on 2003/12/22 08:15:50 UTC

RE: [rc5 / bug / MetadataManager] Memory leak using dynamic mappi ng on per thread bases [ why we need a frech copy!!!]

thanx for diving into this bug,

>What I don't understand is how you could find the leak, because the 
>intention of 'per-thread-changes' use is *not* to copy the repository 
>for each call/thread, rather to manage a bunch of different repositories
>(e.g. by using MetadataManager#addProfile/loadProfile... methods).

>Why you need a 'fresh'copy for each thread/call? Could be a performance 
>problem - maybe I misinterpret your needs.

for every persistence operation (query/store/delete/etc...) we instantiate a
new persistence broker, to my knowledgde, this is supposed to be common
practice. in our webapp we inplemented a relation service that manages
relations between objects. a relation is of a certain relationtype has
references to the related objects, these references are by object id.
relations can be of many different types, and thus may have references to
many different types of objects. we may query our objects on attributes of
related objects, so every Linkable (a marker interface) object implements a
collection links/relations, which contains a collection of related objects.
it is not scalable to implement a new collection for every new relation
type, or for every new linkable target object class. we are going to have
many of these, it just is not managable (in java-classes, in O/R
repositories etc.). So each Linkable class implements one links/relations
collection, which has a 'dummy' mapping in the  O/R repository file.
Runtime, dynamically, this mapping is modified and set to the correct
references, because for instance when issuing a query, we know what class
and link references to use. This may change for every query!

So this is why we copy the repository every time.

Hope this gives you some insight in how we use this feature.

thanx again,

Roger Janssen


*************************************************************************
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.

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


Re: [rc5 / bug / MetadataManager] Memory leak using dynamic mappi ng on per thread bases [ why we need a frech copy!!!]

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Roger,

Janssen, Roger wrote:
...
>>Why you need a 'fresh'copy for each thread/call? Could be a performance 
>>problem - maybe I misinterpret your needs.
> 
> 
> for every persistence operation (query/store/delete/etc...) we instantiate a
> new persistence broker, to my knowledgde, this is supposed to be common
> practice.

right, get instance from pool for each action and close (return to pool) 
after use.

> in our webapp we inplemented a relation service that manages
> relations between objects. a relation is of a certain relationtype has
> references to the related objects, these references are by object id.
> relations can be of many different types, and thus may have references to
> many different types of objects. we may query our objects on attributes of
> related objects, so every Linkable (a marker interface) object implements a
> collection links/relations, which contains a collection of related objects.
> it is not scalable to implement a new collection for every new relation
> type, or for every new linkable target object class. we are going to have
> many of these, it just is not managable (in java-classes, in O/R
> repositories etc.). So each Linkable class implements one links/relations
> collection, which has a 'dummy' mapping in the  O/R repository file.
> Runtime, dynamically, this mapping is modified and set to the correct
> references, because for instance when issuing a query, we know what class
> and link references to use. This may change for every query!
> 
> So this is why we copy the repository every time.
> 
> Hope this gives you some insight in how we use this feature.
> 
wow, incredible! Does this mean that users can change/manipulate 
relations of objects at runtime?

As your case of metadata manipulation is exceptionally, do you have any 
special wishes/proposals/suggestions for improvement for OJB 1.1?
Some ideas are:
- Make MetadataManager pluggable (but I don't know if we can guarantee a 
stable interface at this time, maybe some method will change in further 
versions)

- Allow metadata manipulation of current used PB instance at PB 
"lifetime" (after request from pool, before return to pool) by using 
PB.setDescriptorRepository(...) method (Currently we have some direct 
dependency to MetadataManager in ObjectFactory and QueryByCriteria, thus 
they wouldn't notified when metadata of current used descriptor change).

regards,
Armin

> thanx again,
> 
> Roger Janssen
> 
> 
> *************************************************************************
> The information contained in this communication is confidential and is
> intended solely for the use of the individual or entity to  whom it is
> addressed.You should not copy, disclose or distribute this communication 
> without the authority of iBanx bv. iBanx bv is neither liable for 
> the proper and complete transmission of the information has been maintained
> nor that the communication is free of viruses, interceptions or interference.
> 
> If you are not the intended recipient of this communication please return
> the communication to the sender and delete and destroy all copies.
> 
> ---------------------------------------------------------------------
> 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