question about synchronization in 1:n relationships

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

question about synchronization in 1:n relationships

Abid Hussain-3
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: [hidden email]
Web: http://www.abid76.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question about synchronization in 1:n relationships

Alessandro Colantoni
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 <[hidden email]>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: [hidden email]
> Web: http://www.abid76.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question about synchronization in 1:n relationships

Abid Hussain-3
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 <[hidden email]>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: [hidden email]
>> Web: http://www.abid76.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

--

Abid Hussain
Mail: [hidden email]
Web: http://www.abid76.de


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question about synchronization in 1:n relationships

Alessandro Colantoni
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 <[hidden email]>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 <[hidden email]
>> >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: [hidden email]
>>> Web: http://www.abid76.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
> --
>
> Abid Hussain
> Mail: [hidden email]
> Web: http://www.abid76.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Loading...