db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Detecting Metadata Changes
Date Tue, 14 Sep 2004 15:06:05 GMT


Brian McCallister wrote:

> The distributed cache is to be used with OJB 1.0.X (we need it at my day 
> job).
> 
> Also, the message getting to the cache looks like:
> 
> <row table="SOME_TABLE_NAME">
>     <key column="PK_COLUMN_1" value="1"/>
>     <key column="PK_COLUMN_2" value="wombat"/>
> </row>
> 
> I need to map that information to an OJB Identity instance to flush from 
> the cache(s). To do this I am searching the descriptor repository for 
> anything mapped to SOME_TABLE_NAME and getting the pk fields.
> 
> The problem is that this mapping information can be changed at any time, 

Could you describe more detailed? Do you mean dynamically metadata 
changes at runtime, e.g. add/remove of class-descriptor? PK field changes?

> so holding on to the (relatively expensive to generate) converter from 
> the row description above to an OJB identity is a losing option for a 
> general solution. As I am pretty sure I will be able to donate this code 
> back into OJB when it is done, I would like to aim for the general 
> solution.
> 

If you using several metadata profiles (OJB per thread association of 
metadata - MetadataManager) each profile use an own DescriptorRepository 
instance and the metadata represented by an DescriptorRepository 
instance should not change at runtime. So you can use a map in 
DescriptorRepository/MetadataManager or a map in an additional class 
bound to the used "profile name".

Armin

> -Brian
> 
> On Sep 14, 2004, at 10:39 AM, Armin Waibel wrote:
> 
>> Hi Brian,
>>
>> Brian McCallister wrote:
>>
>>> I am working on a distributed cache implementation which transmits 
>>> dirties only, and transmits just the table and pk information (over 
>>> JMS (using ActiveCluster)) so that non-OJB clients can dirty caches.
>>> A problem I am having is how to detect runtime changes of metadata.
>>
>>
>> Think I don't get your point. In 1.1 OJB use several cache if 
>> necessary. So if e.g. someone use the same connection with different 
>> metadata-model, OJB use different cache instances and transmit dirties 
>> autonomous. The caches register each other as 'InvalidationListener' 
>> and if cache A update an object it invalidates this object in cache B 
>> (and vice versa).
>>
>> So your Distributed ObjectCache implementation shouldn't have to think 
>> about it.
>>
>> regards,
>> Armin
>>
>>
>>> Searching the entire repository for every dirty even received is a 
>>> terrible option, imho, but caching the descriptor information is 
>>> risky as heck as there is no mechanism for detecting runtime metadata 
>>> changes of which I am aware.
>>> Is there one I don't know about?
>>> If not the workaround is simply to tell anyone using this cache that 
>>> they need to call a static method (which will broadcast the change 
>>> notification) when they make runtime metadata changes if they are 
>>> using this cache.
>>> Thanks,
>>> Brian
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

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


Mime
View raw message