[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ojb-user
Subject:    Re: question about synchronization in 1:n relationships
From:       "Alessandro Colantoni" <alessandro.colantoni () gmail ! com>
Date:       2008-10-24 14:43:58
Message-ID: 59f42c000810240743u7963c2fl13de17f3bbe2fe15 () mail ! gmail ! com
[Download RAW message or body]


Hi Abid
About the refresh-attribute, I think you well understood, even if I never
used it. Anyway it should be easy to try.
The two level is not a performance improvement, but it is more that other
that the change you make on the cache can be seen by other user when you end
up the transaction, (persistencebroker.close,  or commit or so on...)

About the synchronization you need, I don't know... I always deal with the
opposite problem. I generally don't want that changes in cache on a side can
influence my job on an other side, until is all finished.

I think that when you lookup something from the cache a new object is
created copying information from the cache. Then it is your own object and
you can do whatever you want on it. Nothing reference the cache. I think
that is the way it works, anyway I never considered your needing.
Anyway with Ojb it is very easy to make your own cache
http://db.apache.org/ojb/docu/guides/objectcache.html#More+implementations+.
..
more ... in the package *org.apache.ojb.broker.cache*  there are more cache
implementation and you could be lucky.
So browse in this package in the source code  and javadoc. If you find out
something tell me. It could be interesting.

Regards

Alessandro




On Fri, Oct 24, 2008 at 3:52 PM, Abid Hussain <abid.hussain@abid76.de>wrote:

> Hi,
>
> first of all, thanks for help and giving me the hints to the docs.
>
> My goal is to avoid keeping objects in my application which are
> unsynchronized with the db.
>
> So far I understood setting the refresh-attribute in collection-descriptor
> to "true" results in refreshing all referenced objects in the collection
> when the object is loaded from cache or database.
>
> Whereas using the two-level-cache only is a performance improvement to keep
> the number of db-lookups small. It doesn't prevent the application from
> having unsynchronized data.
>
> Maybe you could give me a hint if my conclusions described above are
> correct in termns of understanding how refresh and two-level-cache works?
>
> Regards,
>
> Abid
>
> Alessandro Colantoni schrieb:
>
>  Hi Abid.
>>
>> Do you mean that you want automatically refreshed the events collection,
>> without any lookup to the cache or not?.
>>
>> If you want the collection to be refreshed on look up you can
>> use collection-descriptor refresh attribute or the two level cache
>> http://db.apache.org/ojb/docu/guides/repository.html#collection-descriptor
>> http://db.apache.org/ojb/docu/guides/objectcache.html#two-level
>>
>> I dont't think you could avoid a lookup, anyway a first idea could be to
>> make it hidden to the eventType user.
>> For example you could hide the lookup in the method getEvents of the class
>> EventType
>>
>> Regards
>> Alessandro
>>
>>
>> On Wed, Oct 22, 2008 at 10:00 AM, Abid Hussain <abid.hussain@abid76.de
>> >wrote:
>>
>>  Hello everybody,
>>>
>>> I except not to be the first one to ask this question, but haven't found
>>> anything in the archives.
>>>
>>> My question is about synchronization resp. caching of 1:n relations.
>>> Let's
>>> say, we have two entities:
>>> class Event {
>>>       int id;
>>>       int eventTypeId;
>>>       EventType eventType;
>>>       // ... other fields
>>> }
>>> class EventType {
>>>       int id;
>>>       Collection<Event> events;
>>>       // ... other fields
>>> }
>>> So, there is a 1:n relationship between EventType and Event - EventType
>>> is
>>> on the 1-side and Event is on the n-side.
>>>
>>> Let's look at the following:
>>> (1) We fetch an EventType (called evType) from DB incl. all the
>>> associated
>>> Events.
>>> (2) Another user deletes an Event from the DB which was associated with
>>> the
>>> previously fetched EventType.
>>> (3) At this point, an Event is included in the evType's events-collection
>>> which doesn't exist any more cause it was deleted in (2).
>>>
>>> Is there any caching or synchronization mechanism to avoid the problem in
>>> (3)?
>>>
>>> Regards,
>>>
>>> Abid
>>>
>>>
>>> --
>>>
>>> Abid Hussain
>>> Mail: abid.hussain@abid76.de
>>> Web: http://www.abid76.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
> --
>
> Abid Hussain
> Mail: abid.hussain@abid76.de
> Web: http://www.abid76.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>


[prev in list] [next in list] [prev in thread] [next in thread]