Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Using CDOView?
[CDO] Using CDOView? [message #423520] Wed, 01 October 2008 18:34 Go to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
When a client uses a CDOView, how does the client access the model
without the view updating the model while the client is accessing it?
Is there a way to "lock" the view?

Bryan
Re: [CDO] Using CDOView? [message #423524 is a reply to message #423520] Wed, 01 October 2008 18:49 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Bryan Hunt schrieb:
> When a client uses a CDOView, how does the client access the model
> without the view updating the model while the client is accessing it?
> Is there a way to "lock" the view?
A CDOView is always a read-only view to the model. You can't modify the
model through a CDOView. So in this sense it's always locked ;-)

Cheers
/Eike


Re: [CDO] Using CDOView? [message #423525 is a reply to message #423524] Wed, 01 October 2008 18:50 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
Ok, but what happens when another client updates the model through a
transaction? Isn't the view updated with the latest model?

Bryan

On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:

> Bryan Hunt schrieb:
>> When a client uses a CDOView, how does the client access the model
>> without the view updating the model while the client is accessing it?
>> Is there a way to "lock" the view?
> A CDOView is always a read-only view to the model. You can't modify the
> model through a CDOView. So in this sense it's always locked ;-)
>
> Cheers
> /Eike
Re: [CDO] Using CDOView? [message #423526 is a reply to message #423525] Wed, 01 October 2008 18:52 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Bryan Hunt schrieb:
> Ok, but what happens when another client updates the model through a
> transaction? Isn't the view updated with the latest model?
Yes, as long as the underlying session of the view has
PassiveUpdateEnabled, which is the default.
The CDOView is, in this case, always seeing the latest state of the model.

A variant is the special CDOAudit view which always looks at the state
of a specified, fixed time. It's also read-only.

Cheers
/Eike
>
> Bryan
>
> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:
>
>> Bryan Hunt schrieb:
>>> When a client uses a CDOView, how does the client access the model
>>> without the view updating the model while the client is accessing
>>> it? Is there a way to "lock" the view?
>> A CDOView is always a read-only view to the model. You can't modify
>> the model through a CDOView. So in this sense it's always locked ;-)
>>
>> Cheers
>> /Eike
>
>


Re: [CDO] Using CDOView? [message #423527 is a reply to message #423526] Wed, 01 October 2008 18:57 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
So, how does one deal with thread-safe issues. If in one thread I'm
iterating over an EList, and in another thread CDO is updating that
EList at the same time, I'll get a ConcurrentModificationException.
How do you prevent that? Without some sort of locking mechanism, I
fail to see how CDOView is of any use.

On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de> said:

> Bryan Hunt schrieb:
>> Ok, but what happens when another client updates the model through a
>> transaction? Isn't the view updated with the latest model?
> Yes, as long as the underlying session of the view has
> PassiveUpdateEnabled, which is the default.
> The CDOView is, in this case, always seeing the latest state of the model.
>
> A variant is the special CDOAudit view which always looks at the state
> of a specified, fixed time. It's also read-only.
>
> Cheers
> /Eike
>>
>> Bryan
>>
>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:
>>
>>> Bryan Hunt schrieb:
>>>> When a client uses a CDOView, how does the client access the model
>>>> without the view updating the model while the client is accessing it?
>>>> Is there a way to "lock" the view?
>>> A CDOView is always a read-only view to the model. You can't modify the
>>> model through a CDOView. So in this sense it's always locked ;-)
>>>
>>> Cheers
>>> /Eike
Re: [CDO] Using CDOView? [message #423534 is a reply to message #423527] Wed, 01 October 2008 20:41 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
It will be another list! :-) When we update, the client (during the
iteration) will access suddenly the new list.
In that case!!!

If you don't want to have passiveupdateenabled please call the following:
session.setPassiveUpdateEnabled(false);
see
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project


"Bryan Hunt" <bhunt@mac.com> a
Re: [CDO] Using CDOView? [message #423539 is a reply to message #423534] Wed, 01 October 2008 22:07 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
So, if I understand this correctly, if I have an object that contains a
list of index : integer with the following values:

0: 20
1: 10
2: 50
3: 20

Now imagine that I have the following loop:

int sum = 0;

for(int value : object.getValues())
sum += value;

Assuming no changes to the model, the sum will be 100. Now, assume
that when the above loop is on index 2 (sum will be 30), that some
other client changes the values to:

0: 20
1: 50
2: 10
3: 20

will sum then end up being 60? That's really bad.


On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com> said:

>
> It will be another list! :-) When we update, the client (during the
> iteration) will access suddenly the new list.
> In that case!!!
>
> If you don't want to have passiveupdateenabled please call the following:
> session.setPassiveUpdateEnabled(false);
> see
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project


"Bryan
>
> Hunt" <bhunt@mac.com> a écrit dans le message de news:
> gc0h6l$jt0$1@build.eclipse.org...
>> So, how does one deal with thread-safe issues. If in one thread I'm
>> iterating over an EList, and in another thread CDO is updating that EList
>> at the same time, I'll get a ConcurrentModificationException. How do you
>> prevent that? Without some sort of locking mechanism, I fail to see how
>> CDOView is of any use.
>>
>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de> said:
>>
>>> Bryan Hunt schrieb:
>>>> Ok, but what happens when another client updates the model through a
>>>> transaction? Isn't the view updated with the latest model?
>>> Yes, as long as the underlying session of the view has
>>> PassiveUpdateEnabled, which is the default.
>>> The CDOView is, in this case, always seeing the latest state of the
>>> model.
>>>
>>> A variant is the special CDOAudit view which always looks at the state of
>>> a specified, fixed time. It's also read-only.
>>>
>>> Cheers
>>> /Eike
>>>>
>>>> Bryan
>>>>
>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>
>>>>> Bryan Hunt schrieb:
>>>>>> When a client uses a CDOView, how does the client access the model
>>>>>> without the view updating the model while the client is accessing it?
>>>>>> Is there a way to "lock" the view?
>>>>> A CDOView is always a read-only view to the model. You can't modify the
>>>>> model through a CDOView. So in this sense it's always locked ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
Re: [CDO] Using CDOView? [message #423540 is a reply to message #423539] Wed, 01 October 2008 22:14 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I'm not sure at 100%. Maybe I'm forgetting something.

But yes I think you will get that result.

Usually the mechanism is used not to calculate critical things. As an
example, from the user interface you will receives notifications as well so
you can update your interface.. etc..
For the processing or to calculate critical things, I think to be safe you
should use passiveUpdateEnabled(false).

Simon



"Bryan Hunt" <bhunt@mac.com> a
Re: [CDO] Using CDOView? [message #423541 is a reply to message #423540] Wed, 01 October 2008 23:10 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
Ok, if I use passiveUpdateEnabled(false), how do find out if there are
updates to the model, and how do I get the model updated after I've
finished processing?

Bryan

On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com> said:

> I'm not sure at 100%. Maybe I'm forgetting something.
>
> But yes I think you will get that result.
>
> Usually the mechanism is used not to calculate critical things. As an
> example, from the user interface you will receives notifications as well so
> you can update your interface.. etc..
> For the processing or to calculate critical things, I think to be safe you
> should use passiveUpdateEnabled(false).
>
> Simon
>
>
>
> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
> gc0sbg$mbv$1@build.eclipse.org...
>> So, if I understand this correctly, if I have an object that contains a
>> list of index : integer with the following values:
>>
>> 0: 20
>> 1: 10
>> 2: 50
>> 3: 20
>>
>> Now imagine that I have the following loop:
>>
>> int sum = 0;
>>
>> for(int value : object.getValues())
>> sum += value;
>>
>> Assuming no changes to the model, the sum will be 100. Now, assume that
>> when the above loop is on index 2 (sum will be 30), that some other client
>> changes the values to:
>>
>> 0: 20
>> 1: 50
>> 2: 10
>> 3: 20
>>
>> will sum then end up being 60? That's really bad.
>>
>>
>> On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com> said:
>>
>>>
>>> It will be another list! :-) When we update, the client (during the
>>> iteration) will access suddenly the new list.
>>> In that case!!!
>>>
>>> If you don't want to have passiveupdateenabled please call the following:
>>> session.setPassiveUpdateEnabled(false);
>>> see
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project


"Bryan

Hunt"
>>>
>>> <bhunt@mac.com> a écrit dans le message de news:
>>> gc0h6l$jt0$1@build.eclipse.org...
>>>> So, how does one deal with thread-safe issues. If in one thread I'm
>>>> iterating over an EList, and in another thread CDO is updating that
>>>> EList
>>>> at the same time, I'll get a ConcurrentModificationException. How do
>>>> you
>>>> prevent that? Without some sort of locking mechanism, I fail to see how
>>>> CDOView is of any use.
>>>>
>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>
>>>>> Bryan Hunt schrieb:
>>>>>> Ok, but what happens when another client updates the model through a
>>>>>> transaction? Isn't the view updated with the latest model?
>>>>> Yes, as long as the underlying session of the view has
>>>>> PassiveUpdateEnabled, which is the default.
>>>>> The CDOView is, in this case, always seeing the latest state of the
>>>>> model.
>>>>>
>>>>> A variant is the special CDOAudit view which always looks at the state
>>>>> of
>>>>> a specified, fixed time. It's also read-only.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>>
>>>>>> Bryan
>>>>>>
>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>>>
>>>>>>> Bryan Hunt schrieb:
>>>>>>>> When a client uses a CDOView, how does the client access the model
>>>>>>>> without the view updating the model while the client is accessing
>>>>>>>> it?
>>>>>>>> Is there a way to "lock" the view?
>>>>>>> A CDOView is always a read-only view to the model. You can't modify
>>>>>>> the
>>>>>>> model through a CDOView. So in this sense it's always locked ;-)
>>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
Re: [CDO] Using CDOView? [message #423542 is a reply to message #423541] Wed, 01 October 2008 23:38 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Good question Bryan!!

If you want to know when a specific object is updated you can do the
following:

- Change Subscription Feature - It will gave you the delta.
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project

When passiveupdate is at false, the only way to have notification is change
subscription.
The pros : It has delta changes.
The cons: Need to add an adapter for every objects.

After that you can call session.refresh() to refresh your objects. To keep
the integrity of the graph you need to refresh every object in your cache,
you cannot refresh only one item.

We also had an idea to have all invalidate notification (without any
subscription) without updating the object. It will not say what changes for
a specific object but it has been changed.
So maybe in that case, passiveUpdate should be a Policy instead of a boolean
value. What you think Eike ?


Simon




"Bryan Hunt" <bhunt@mac.com> a
Re: [CDO] Using CDOView? [message #423543 is a reply to message #423542] Wed, 01 October 2008 23:42 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
PassiveUpdatePolicy
- NONE
- NOTIFY
- NOTIFYANDUPDATE

Default will be NOTIFYANDUPDATE.

"Simon McDuff" <smcduff@hotmail.com> a
Re: [CDO] Using CDOView? [message #423549 is a reply to message #423543] Thu, 02 October 2008 06:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> PassiveUpdatePolicy
> - NONE
> - NOTIFY
> - NOTIFYANDUPDATE
>
> Default will be NOTIFYANDUPDATE.
>
I'm not sure if this would really help in Bryan's particular case.
Would NOTIFY include a CDOEvent.INVALIDATE?
In this case the object would be in CDOState.PROXY and Bryan's
next loop access would actively update the object before returning
any data. The same effect as immediate passive update.

I have two additional ideas that we could discusss:

1) PassiveUpdatePolicy

- NONE
- NOTIFY
- UPDATE
- BATCH (means no change in network protocol but local buffering until the policy is changed back to "normal")

2) Explicit Locking
- Either on CDOObject level (probably prone to deadlocks caused by wrong lock ordering)
- or better on CDOView level (I prefer this variant. The framework would lock the whole view during remote updates and the client can decide if he needs to protect non-atomic operations or not)

Cheers
/Eike




> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de news:
> gc11ls$img$1@build.eclipse.org...
>
>> Good question Bryan!!
>>
>> If you want to know when a specific object is updated you can do the
>> following:
>>
>> - Change Subscription Feature - It will gave you the delta.
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>
>> When passiveupdate is at false, the only way to have notification is
>> change subscription.
>> The pros : It has delta changes.
>> The cons: Need to add an adapter for every objects.
>>
>> After that you can call session.refresh() to refresh your objects. To keep
>> the integrity of the graph you need to refresh every object in your cache,
>> you cannot refresh only one item.
>>
>> We also had an idea to have all invalidate notification (without any
>> subscription) without updating the object. It will not say what changes
>> for a specific object but it has been changed.
>> So maybe in that case, passiveUpdate should be a Policy instead of a
>> boolean value. What you think Eike ?
>>
>>
>> Simon
>>
>>
>>
>>
>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>> gc101b$paq$1@build.eclipse.org...
>>
>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there are
>>> updates to the model, and how do I get the model updated after I've
>>> finished processing?
>>>
>>> Bryan
>>>
>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com> said:
>>>
>>>
>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>
>>>> But yes I think you will get that result.
>>>>
>>>> Usually the mechanism is used not to calculate critical things. As an
>>>> example, from the user interface you will receives notifications as well
>>>> so
>>>> you can update your interface.. etc..
>>>> For the processing or to calculate critical things, I think to be safe
>>>> you
>>>> should use passiveUpdateEnabled(false).
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>
>>>>> So, if I understand this correctly, if I have an object that contains a
>>>>> list of index : integer with the following values:
>>>>>
>>>>> 0: 20
>>>>> 1: 10
>>>>> 2: 50
>>>>> 3: 20
>>>>>
>>>>> Now imagine that I have the following loop:
>>>>>
>>>>> int sum = 0;
>>>>>
>>>>> for(int value : object.getValues())
>>>>> sum += value;
>>>>>
>>>>> Assuming no changes to the model, the sum will be 100. Now, assume
>>>>> that
>>>>> when the above loop is on index 2 (sum will be 30), that some other
>>>>> client
>>>>> changes the values to:
>>>>>
>>>>> 0: 20
>>>>> 1: 50
>>>>> 2: 10
>>>>> 3: 20
>>>>>
>>>>> will sum then end up being 60? That's really bad.
>>>>>
>>>>>
>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>> said:
>>>>>
>>>>>
>>>>>> It will be another list! :-) When we update, the client (during the
>>>>>> iteration) will access suddenly the new list.
>>>>>> In that case!!!
>>>>>>
>>>>>> If you don't want to have passiveupdateenabled please call the
>>>>>> following:
>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>> see
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>
>>> "Bryan
>>>
>>> Hunt"
>>>
>>>>>> <bhunt@mac.com> a écrit dans le message de news:
>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>
>>>>>>> So, how does one deal with thread-safe issues. If in one thread I'm
>>>>>>> iterating over an EList, and in another thread CDO is updating that
>>>>>>> EList
>>>>>>> at the same time, I'll get a ConcurrentModificationException. How do
>>>>>>> you
>>>>>>> prevent that? Without some sort of locking mechanism, I fail to see
>>>>>>> how
>>>>>>> CDOView is of any use.
>>>>>>>
>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>>>>
>>>>>>>
>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>
>>>>>>>>> Ok, but what happens when another client updates the model through
>>>>>>>>> a
>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>
>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>> The CDOView is, in this case, always seeing the latest state of the
>>>>>>>> model.
>>>>>>>>
>>>>>>>> A variant is the special CDOAudit view which always looks at the
>>>>>>>> state
>>>>>>>> of
>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>> Bryan
>>>>>>>>>
>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de>
>>>>>>>>> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>
>>>>>>>>>>> When a client uses a CDOView, how does the client access the
>>>>>>>>>>> model
>>>>>>>>>>> without the view updating the model while the client is accessing
>>>>>>>>>>> it?
>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>
>>>>>>>>>> A CDOView is always a read-only view to the model. You can't
>>>>>>>>>> modify
>>>>>>>>>> the
>>>>>>>>>> model through a CDOView. So in this sense it's always locked ;-)
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> /Eike
>>>>>>>>>>
>>>
>>
>
>
>


Re: [CDO] Using CDOView? [message #423578 is a reply to message #423549] Thu, 02 October 2008 13:57 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO] Using CDOView? [message #423580 is a reply to message #423549] Thu, 02 October 2008 14:50 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
On 2008-10-02 01:17:14 -0500, Eike Stepper <stepper@esc-net.de> said:

> Simon McDuff schrieb:
>> PassiveUpdatePolicy
>> - NONE
>> - NOTIFY
>> - NOTIFYANDUPDATE
>>
>> Default will be NOTIFYANDUPDATE.
>>
> I'm not sure if this would really help in Bryan's particular case.
> Would NOTIFY include a CDOEvent.INVALIDATE?
> In this case the object would be in CDOState.PROXY and Bryan's
> next loop access would actively update the object before returning
> any data. The same effect as immediate passive update.
>
> I have two additional ideas that we could discusss:
>
> 1) PassiveUpdatePolicy
>
> - NONE
> - NOTIFY
> - UPDATE
> - BATCH (means no change in network protocol but local buffering until
> the policy is changed back to "normal")
>
> 2) Explicit Locking
> - Either on CDOObject level (probably prone to deadlocks caused by
> wrong lock ordering)
> - or better on CDOView level (I prefer this variant. The framework
> would lock the whole view during remote updates and the client can
> decide if he needs to protect non-atomic operations or not)

I think adding a lock() and unlock() to CDOView would be preferred in
my case. I have a model that is based on a composite pattern which
allows a user to construct a tree structure. When the model is saved,
a server needs to see the new model. The server does not care about
the individual updates to the model since it must walk the entire tree
in one pass of the algorithm. The server walks the tree periodically
(possibly as often as once per second) and while it is walking the
tree, the model, obviously, cannot change. It therefore seems the
easiest thing for me to do is:

while(true)
{
view.lock();
processModel();
view.unlock();
sleep(time);
}

If this is something you find worthy of inclusion in CDO, could this go
in soon (ie, next couple of days), or are there other high priority
items ahead of it? I think I might try using CDOAudit as a workaround.

Thanks for taking the time to help me understand CDO.

Bryan

>
> Cheers
> /Eike
>
>
>
>
>> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de news:
>> gc11ls$img$1@build.eclipse.org...
>>
>>> Good question Bryan!!
>>>
>>> If you want to know when a specific object is updated you can do the
>>> following:
>>>
>>> - Change Subscription Feature - It will gave you the delta.
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project

When
>>>
>>> passiveupdate is at false, the only way to have notification is change
>>> subscription.
>>> The pros : It has delta changes.
>>> The cons: Need to add an adapter for every objects.
>>>
>>> After that you can call session.refresh() to refresh your objects. To
>>> keep the integrity of the graph you need to refresh every object in
>>> your cache, you cannot refresh only one item.
>>>
>>> We also had an idea to have all invalidate notification (without any
>>> subscription) without updating the object. It will not say what changes
>>> for a specific object but it has been changed.
>>> So maybe in that case, passiveUpdate should be a Policy instead of a
>>> boolean value. What you think Eike ?
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>> gc101b$paq$1@build.eclipse.org...
>>>
>>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there are
>>>> updates to the model, and how do I get the model updated after I've
>>>> finished processing?
>>>>
>>>> Bryan
>>>>
>>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com> said:
>>>>
>>>>
>>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>>
>>>>> But yes I think you will get that result.
>>>>>
>>>>> Usually the mechanism is used not to calculate critical things. As an
>>>>> example, from the user interface you will receives notifications as well so
>>>>> you can update your interface.. etc..
>>>>> For the processing or to calculate critical things, I think to be safe you
>>>>> should use passiveUpdateEnabled(false).
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>>
>>>>>> So, if I understand this correctly, if I have an object that contains a
>>>>>> list of index : integer with the following values:
>>>>>>
>>>>>> 0: 20
>>>>>> 1: 10
>>>>>> 2: 50
>>>>>> 3: 20
>>>>>>
>>>>>> Now imagine that I have the following loop:
>>>>>>
>>>>>> int sum = 0;
>>>>>>
>>>>>> for(int value : object.getValues())
>>>>>> sum += value;
>>>>>>
>>>>>> Assuming no changes to the model, the sum will be 100. Now, assume that
>>>>>> when the above loop is on index 2 (sum will be 30), that some other client
>>>>>> changes the values to:
>>>>>>
>>>>>> 0: 20
>>>>>> 1: 50
>>>>>> 2: 10
>>>>>> 3: 20
>>>>>>
>>>>>> will sum then end up being 60? That's really bad.
>>>>>>
>>>>>>
>>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com> said:
>>>>>>
>>>>>>
>>>>>>> It will be another list! :-) When we update, the client (during the
>>>>>>> iteration) will access suddenly the new list.
>>>>>>> In that case!!!
>>>>>>>
>>>>>>> If you don't want to have passiveupdateenabled please call the following:
>>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>>> see
>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project

"Bryan

Hunt"

<bhunt@mac.com>
>>>>>>>
>>>>>>> a écrit dans le message de news:
>>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>>
>>>>>>>> So, how does one deal with thread-safe issues. If in one thread I'm
>>>>>>>> iterating over an EList, and in another thread CDO is updating that
>>>>>>>> EList
>>>>>>>> at the same time, I'll get a ConcurrentModificationException. How do
>>>>>>>> you
>>>>>>>> prevent that? Without some sort of locking mechanism, I fail to see how
>>>>>>>> CDOView is of any use.
>>>>>>>>
>>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>
>>>>>>>>>> Ok, but what happens when another client updates the model through a
>>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>>
>>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>>> The CDOView is, in this case, always seeing the latest state of the
>>>>>>>>> model.
>>>>>>>>>
>>>>>>>>> A variant is the special CDOAudit view which always looks at the state
>>>>>>>>> of
>>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> /Eike
>>>>>>>>>
>>>>>>>>>> Bryan
>>>>>>>>>>
>>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de> said:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>
>>>>>>>>>>>> When a client uses a CDOView, how does the client access the model
>>>>>>>>>>>> without the view updating the model while the client is accessing
>>>>>>>>>>>> it?
>>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>>
>>>>>>>>>>> A CDOView is always a read-only view to the model. You can't modify
>>>>>>>>>>> the
>>>>>>>>>>> model through a CDOView. So in this sense it's always locked ;-)
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> /Eike
>>>>>>>>>>>
>>>>
>>>
>>
>>
>>
Re: [CDO] Using CDOView? [message #423584 is a reply to message #423549] Thu, 02 October 2008 15:33 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
> 2) Explicit Locking
> - Either on CDOObject level (probably prone to deadlocks caused by wrong
> lock ordering)
> - or better on CDOView level (I prefer this variant. The framework would
> lock the whole view during remote updates and the client can decide if he
> needs to protect non-atomic operations or not)
>

The lock would be on the session right ? Since the session control the
revisions...
session.lock()
session.unlock().


"Eike Stepper" <stepper@esc-net.de> wrote in message
news:gc1p1d$lt0$1@build.eclipse.org...
> Simon McDuff schrieb:
>> PassiveUpdatePolicy
>> - NONE
>> - NOTIFY
>> - NOTIFYANDUPDATE
>>
>> Default will be NOTIFYANDUPDATE.
>>
> I'm not sure if this would really help in Bryan's particular case.
> Would NOTIFY include a CDOEvent.INVALIDATE?
> In this case the object would be in CDOState.PROXY and Bryan's
> next loop access would actively update the object before returning
> any data. The same effect as immediate passive update.
>
> I have two additional ideas that we could discusss:
>
> 1) PassiveUpdatePolicy
>
> - NONE
> - NOTIFY
> - UPDATE
> - BATCH (means no change in network protocol but local buffering until the
> policy is changed back to "normal")
>
> 2) Explicit Locking
> - Either on CDOObject level (probably prone to deadlocks caused by wrong
> lock ordering)
> - or better on CDOView level (I prefer this variant. The framework would
> lock the whole view during remote updates and the client can decide if he
> needs to protect non-atomic operations or not)
>
> Cheers
> /Eike
>
>
>
>
>> "Simon McDuff" <smcduff@hotmail.com> a
Re: [CDO] Using CDOView? [message #423591 is a reply to message #423584] Thu, 02 October 2008 17:49 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon McDuff schrieb:
>> 2) Explicit Locking
>> - Either on CDOObject level (probably prone to deadlocks caused by wrong
>> lock ordering)
>> - or better on CDOView level (I prefer this variant. The framework would
>> lock the whole view during remote updates and the client can decide if he
>> needs to protect non-atomic operations or not)
>>
>>
>
> The lock would be on the session right ? Since the session control the
> revisions...
> session.lock()
> session.unlock().
>
No, I think CDORevisions don't need protection because they're immutable
(with very few internal exceptions).
We need to protect the CDOObject agains framework-initiated switch of
the associated revision.
I think this is a CDOView responsibility. If we agrre here I'd prefer
this new API in CDOView:

public java.util.concurrent.locks.Lock getLock();


> "Eike Stepper" <stepper@esc-net.de> wrote in message
> news:gc1p1d$lt0$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> PassiveUpdatePolicy
>>> - NONE
>>> - NOTIFY
>>> - NOTIFYANDUPDATE
>>>
>>> Default will be NOTIFYANDUPDATE.
>>>
>>>
>> I'm not sure if this would really help in Bryan's particular case.
>> Would NOTIFY include a CDOEvent.INVALIDATE?
>> In this case the object would be in CDOState.PROXY and Bryan's
>> next loop access would actively update the object before returning
>> any data. The same effect as immediate passive update.
>>
>> I have two additional ideas that we could discusss:
>>
>> 1) PassiveUpdatePolicy
>>
>> - NONE
>> - NOTIFY
>> - UPDATE
>> - BATCH (means no change in network protocol but local buffering until the
>> policy is changed back to "normal")
>>
>> 2) Explicit Locking
>> - Either on CDOObject level (probably prone to deadlocks caused by wrong
>> lock ordering)
>> - or better on CDOView level (I prefer this variant. The framework would
>> lock the whole view during remote updates and the client can decide if he
>> needs to protect non-atomic operations or not)
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>>
>>> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de news:
>>> gc11ls$img$1@build.eclipse.org...
>>>
>>>
>>>> Good question Bryan!!
>>>>
>>>> If you want to know when a specific object is updated you can do the
>>>> following:
>>>>
>>>> - Change Subscription Feature - It will gave you the delta.
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>
>>>> When passiveupdate is at false, the only way to have notification is
>>>> change subscription.
>>>> The pros : It has delta changes.
>>>> The cons: Need to add an adapter for every objects.
>>>>
>>>> After that you can call session.refresh() to refresh your objects. To
>>>> keep the integrity of the graph you need to refresh every object in your
>>>> cache, you cannot refresh only one item.
>>>>
>>>> We also had an idea to have all invalidate notification (without any
>>>> subscription) without updating the object. It will not say what changes
>>>> for a specific object but it has been changed.
>>>> So maybe in that case, passiveUpdate should be a Policy instead of a
>>>> boolean value. What you think Eike ?
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>> gc101b$paq$1@build.eclipse.org...
>>>>
>>>>
>>>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there are
>>>>> updates to the model, and how do I get the model updated after I've
>>>>> finished processing?
>>>>>
>>>>> Bryan
>>>>>
>>>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>> said:
>>>>>
>>>>>
>>>>>
>>>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>>>
>>>>>> But yes I think you will get that result.
>>>>>>
>>>>>> Usually the mechanism is used not to calculate critical things. As an
>>>>>> example, from the user interface you will receives notifications as
>>>>>> well so
>>>>>> you can update your interface.. etc..
>>>>>> For the processing or to calculate critical things, I think to be safe
>>>>>> you
>>>>>> should use passiveUpdateEnabled(false).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>>>
>>>>>>
>>>>>>> So, if I understand this correctly, if I have an object that contains
>>>>>>> a
>>>>>>> list of index : integer with the following values:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 10
>>>>>>> 2: 50
>>>>>>> 3: 20
>>>>>>>
>>>>>>> Now imagine that I have the following loop:
>>>>>>>
>>>>>>> int sum = 0;
>>>>>>>
>>>>>>> for(int value : object.getValues())
>>>>>>> sum += value;
>>>>>>>
>>>>>>> Assuming no changes to the model, the sum will be 100. Now, assume
>>>>>>> that
>>>>>>> when the above loop is on index 2 (sum will be 30), that some other
>>>>>>> client
>>>>>>> changes the values to:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 50
>>>>>>> 2: 10
>>>>>>> 3: 20
>>>>>>>
>>>>>>> will sum then end up being 60? That's really bad.
>>>>>>>
>>>>>>>
>>>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>>>> said:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> It will be another list! :-) When we update, the client (during the
>>>>>>>> iteration) will access suddenly the new list.
>>>>>>>> In that case!!!
>>>>>>>>
>>>>>>>> If you don't want to have passiveupdateenabled please call the
>>>>>>>> following:
>>>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>>>> see
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>>>
>>>>>>>>
>>>>> "Bryan
>>>>>
>>>>> Hunt"
>>>>>
>>>>>
>>>>>>>> <bhunt@mac.com> a écrit dans le message de news:
>>>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>>>
>>>>>>>>
>>>>>>>>> So, how does one deal with thread-safe issues. If in one thread
>>>>>>>>> I'm
>>>>>>>>> iterating over an EList, and in another thread CDO is updating that
>>>>>>>>> EList
>>>>>>>>> at the same time, I'll get a ConcurrentModificationException. How
>>>>>>>>> do
>>>>>>>>> you
>>>>>>>>> prevent that? Without some sort of locking mechanism, I fail to
>>>>>>>>> see how
>>>>>>>>> CDOView is of any use.
>>>>>>>>>
>>>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de>
>>>>>>>>> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Ok, but what happens when another client updates the model
>>>>>>>>>>> through a
>>>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>>>> The CDOView is, in this case, always seeing the latest state of
>>>>>>>>>> the
>>>>>>>>>> model.
>>>>>>>>>>
>>>>>>>>>> A variant is the special CDOAudit view which always looks at the
>>>>>>>>>> state
>>>>>>>>>> of
>>>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> /Eike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Bryan
>>>>>>>>>>>
>>>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de>
>>>>>>>>>>> said:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> When a client uses a CDOView, how does the client access the
>>>>>>>>>>>>> model
>>>>>>>>>>>>> without the view updating the model while the client is
>>>>>>>>>>>>> accessing
>>>>>>>>>>>>> it?
>>>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> A CDOView is always a read-only view to the model. You can't
>>>>>>>>>>>> modify
>>>>>>>>>>>> the
>>>>>>>>>>>> model through a CDOView. So in this sense it's always locked ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> /Eike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>>
>
>
>


Re: [CDO] Using CDOView? [message #423592 is a reply to message #423580] Thu, 02 October 2008 18:03 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Bryan Hunt schrieb:
> [...] I think adding a lock() and unlock() to CDOView would be
> preferred in my case. I have a model that is based on a composite
> pattern which allows a user to construct a tree structure. When the
> model is saved, a server needs to see the new model.
I guess from a CDO perspective this server acts like a regular
repository client? Maybe with a IJVMConnector?

> The server does not care about the individual updates to the model
> since it must walk the entire tree in one pass of the algorithm. The
> server walks the tree periodically (possibly as often as once per
> second) and while it is walking the tree, the model, obviously, cannot
> change. It therefore seems the easiest thing for me to do is:
>
> while(true)
> {
> view.lock();
> processModel();
> view.unlock();
> sleep(time);
> }
>
> If this is something you find worthy of inclusion in CDO, could this
> go in soon (ie, next couple of days), or are there other high priority
> items ahead of it?
I think Simon is busy with other important things (I have never
important things to do ;-) ).
I'm willing to address this feature around the middle of next week
because I'm off over the weekend.

> I think I might try using CDOAudit as a workaround.
If you make your client-side Revision cache large enough this can be a
good alternative.
Just in case you're going to ask, The revision caches at bot client and
server side have a similar structure by default. They're two-level with
a fixed size LRU cache at level 1 and a memory sensitive cache at
level2. For the LRU cache you can configure independently the capacity
for current and "old" revisions. Unfortunately not through public API,
watch:

243279: Add caching properties to CDOSessionConfiguration
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243279

Cheers
/Eike

>
> Thanks for taking the time to help me understand CDO.
>
> Bryan
>
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>>> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de
>>> news: gc11ls$img$1@build.eclipse.org...
>>>
>>>> Good question Bryan!!
>>>>
>>>> If you want to know when a specific object is updated you can do
>>>> the following:
>>>>
>>>> - Change Subscription Feature - It will gave you the delta.
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>
>
> When
>>>>
>>>> passiveupdate is at false, the only way to have notification is
>>>> change subscription.
>>>> The pros : It has delta changes.
>>>> The cons: Need to add an adapter for every objects.
>>>>
>>>> After that you can call session.refresh() to refresh your objects.
>>>> To keep the integrity of the graph you need to refresh every object
>>>> in your cache, you cannot refresh only one item.
>>>>
>>>> We also had an idea to have all invalidate notification (without
>>>> any subscription) without updating the object. It will not say what
>>>> changes for a specific object but it has been changed.
>>>> So maybe in that case, passiveUpdate should be a Policy instead of
>>>> a boolean value. What you think Eike ?
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>> gc101b$paq$1@build.eclipse.org...
>>>>
>>>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there
>>>>> are updates to the model, and how do I get the model updated after
>>>>> I've finished processing?
>>>>>
>>>>> Bryan
>>>>>
>>>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>> said:
>>>>>
>>>>>
>>>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>>>
>>>>>> But yes I think you will get that result.
>>>>>>
>>>>>> Usually the mechanism is used not to calculate critical things.
>>>>>> As an
>>>>>> example, from the user interface you will receives notifications
>>>>>> as well so
>>>>>> you can update your interface.. etc..
>>>>>> For the processing or to calculate critical things, I think to be
>>>>>> safe you
>>>>>> should use passiveUpdateEnabled(false).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>>>
>>>>>>> So, if I understand this correctly, if I have an object that
>>>>>>> contains a
>>>>>>> list of index : integer with the following values:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 10
>>>>>>> 2: 50
>>>>>>> 3: 20
>>>>>>>
>>>>>>> Now imagine that I have the following loop:
>>>>>>>
>>>>>>> int sum = 0;
>>>>>>>
>>>>>>> for(int value : object.getValues())
>>>>>>> sum += value;
>>>>>>>
>>>>>>> Assuming no changes to the model, the sum will be 100. Now,
>>>>>>> assume that
>>>>>>> when the above loop is on index 2 (sum will be 30), that some
>>>>>>> other client
>>>>>>> changes the values to:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 50
>>>>>>> 2: 10
>>>>>>> 3: 20
>>>>>>>
>>>>>>> will sum then end up being 60? That's really bad.
>>>>>>>
>>>>>>>
>>>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff"
>>>>>>> <smcduff@hotmail.com> said:
>>>>>>>
>>>>>>>
>>>>>>>> It will be another list! :-) When we update, the client (during
>>>>>>>> the
>>>>>>>> iteration) will access suddenly the new list.
>>>>>>>> In that case!!!
>>>>>>>>
>>>>>>>> If you don't want to have passiveupdateenabled please call the
>>>>>>>> following:
>>>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>>>> see
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>>>
>
> "Bryan
>
> Hunt"
>
> <bhunt@mac.com>
>>>>>>>>
>>>>>>>> a écrit dans le message de news:
>>>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>>>
>>>>>>>>> So, how does one deal with thread-safe issues. If in one
>>>>>>>>> thread I'm
>>>>>>>>> iterating over an EList, and in another thread CDO is updating
>>>>>>>>> that
>>>>>>>>> EList
>>>>>>>>> at the same time, I'll get a ConcurrentModificationException.
>>>>>>>>> How do
>>>>>>>>> you
>>>>>>>>> prevent that? Without some sort of locking mechanism, I fail
>>>>>>>>> to see how
>>>>>>>>> CDOView is of any use.
>>>>>>>>>
>>>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper
>>>>>>>>> <stepper@esc-net.de> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>
>>>>>>>>>>> Ok, but what happens when another client updates the model
>>>>>>>>>>> through a
>>>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>>>
>>>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>>>> The CDOView is, in this case, always seeing the latest state
>>>>>>>>>> of the
>>>>>>>>>> model.
>>>>>>>>>>
>>>>>>>>>> A variant is the special CDOAudit view which always looks at
>>>>>>>>>> the state
>>>>>>>>>> of
>>>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> /Eike
>>>>>>>>>>
>>>>>>>>>>> Bryan
>>>>>>>>>>>
>>>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper
>>>>>>>>>>> <stepper@esc-net.de> said:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>> When a client uses a CDOView, how does the client access
>>>>>>>>>>>>> the model
>>>>>>>>>>>>> without the view updating the model while the client is
>>>>>>>>>>>>> accessing
>>>>>>>>>>>>> it?
>>>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>>>
>>>>>>>>>>>> A CDOView is always a read-only view to the model. You
>>>>>>>>>>>> can't modify
>>>>>>>>>>>> the
>>>>>>>>>>>> model through a CDOView. So in this sense it's always
>>>>>>>>>>>> locked ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> /Eike
>>>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>


Re: [CDO] Using CDOView? [message #423593 is a reply to message #423591] Thu, 02 October 2008 18:06 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
The CDORevision contained by CDOObject could be revised (Since CDOSession
control them).

If you see no problem in that it should work.

Simon

"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO] Using CDOView? [message #423595 is a reply to message #423593] Thu, 02 October 2008 18:22 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> The CDORevision contained by CDOObject could be revised (Since CDOSession
> control them).
>
Yes, that's the internal exception I meant ;-)
But the client of a CDOView will not realize that directly (again with
possible exception in very recent audit views, in which case this does
not end in changed modeled state).
It will rather notice it through the second effect of remote update:
Switch of the associated revision to the current one. And I still think
that protection against this is best provided through the CDOView.

Am I wrong?

Cheers
/Eike

> If you see no problem in that it should work.
>
> Simon
>
> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> gc31jk$i29$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>>> 2) Explicit Locking
>>>> - Either on CDOObject level (probably prone to deadlocks caused by wrong
>>>> lock ordering)
>>>> - or better on CDOView level (I prefer this variant. The framework would
>>>> lock the whole view during remote updates and the client can decide if
>>>> he needs to protect non-atomic operations or not)
>>>>
>>>>
>>>>
>>> The lock would be on the session right ? Since the session control the
>>> revisions...
>>> session.lock()
>>> session.unlock().
>>>
>>>
>> No, I think CDORevisions don't need protection because they're immutable
>> (with very few internal exceptions).
>> We need to protect the CDOObject agains framework-initiated switch of the
>> associated revision.
>> I think this is a CDOView responsibility. If we agrre here I'd prefer this
>> new API in CDOView:
>>
>> public java.util.concurrent.locks.Lock getLock();
>>
>>
>>
>>> "Eike Stepper" <stepper@esc-net.de> wrote in message
>>> news:gc1p1d$lt0$1@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>> PassiveUpdatePolicy
>>>>> - NONE
>>>>> - NOTIFY
>>>>> - NOTIFYANDUPDATE
>>>>>
>>>>> Default will be NOTIFYANDUPDATE.
>>>>>
>>>>>
>>>>>
>>>> I'm not sure if this would really help in Bryan's particular case.
>>>> Would NOTIFY include a CDOEvent.INVALIDATE?
>>>> In this case the object would be in CDOState.PROXY and Bryan's
>>>> next loop access would actively update the object before returning
>>>> any data. The same effect as immediate passive update.
>>>>
>>>> I have two additional ideas that we could discusss:
>>>>
>>>> 1) PassiveUpdatePolicy
>>>>
>>>> - NONE
>>>> - NOTIFY
>>>> - UPDATE
>>>> - BATCH (means no change in network protocol but local buffering until
>>>> the policy is changed back to "normal")
>>>>
>>>> 2) Explicit Locking
>>>> - Either on CDOObject level (probably prone to deadlocks caused by wrong
>>>> lock ordering)
>>>> - or better on CDOView level (I prefer this variant. The framework would
>>>> lock the whole view during remote updates and the client can decide if
>>>> he needs to protect non-atomic operations or not)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de news:
>>>>> gc11ls$img$1@build.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>> Good question Bryan!!
>>>>>>
>>>>>> If you want to know when a specific object is updated you can do the
>>>>>> following:
>>>>>>
>>>>>> - Change Subscription Feature - It will gave you the delta.
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>
>>>>>> When passiveupdate is at false, the only way to have notification is
>>>>>> change subscription.
>>>>>> The pros : It has delta changes.
>>>>>> The cons: Need to add an adapter for every objects.
>>>>>>
>>>>>> After that you can call session.refresh() to refresh your objects. To
>>>>>> keep the integrity of the graph you need to refresh every object in
>>>>>> your cache, you cannot refresh only one item.
>>>>>>
>>>>>> We also had an idea to have all invalidate notification (without any
>>>>>> subscription) without updating the object. It will not say what
>>>>>> changes for a specific object but it has been changed.
>>>>>> So maybe in that case, passiveUpdate should be a Policy instead of a
>>>>>> boolean value. What you think Eike ?
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>>> gc101b$paq$1@build.eclipse.org...
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there
>>>>>>> are updates to the model, and how do I get the model updated after
>>>>>>> I've finished processing?
>>>>>>>
>>>>>>> Bryan
>>>>>>>
>>>>>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>>>> said:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>>>>>
>>>>>>>> But yes I think you will get that result.
>>>>>>>>
>>>>>>>> Usually the mechanism is used not to calculate critical things. As
>>>>>>>> an
>>>>>>>> example, from the user interface you will receives notifications as
>>>>>>>> well so
>>>>>>>> you can update your interface.. etc..
>>>>>>>> For the processing or to calculate critical things, I think to be
>>>>>>>> safe you
>>>>>>>> should use passiveUpdateEnabled(false).
>>>>>>>>
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> So, if I understand this correctly, if I have an object that
>>>>>>>>> contains a
>>>>>>>>> list of index : integer with the following values:
>>>>>>>>>
>>>>>>>>> 0: 20
>>>>>>>>> 1: 10
>>>>>>>>> 2: 50
>>>>>>>>> 3: 20
>>>>>>>>>
>>>>>>>>> Now imagine that I have the following loop:
>>>>>>>>>
>>>>>>>>> int sum = 0;
>>>>>>>>>
>>>>>>>>> for(int value : object.getValues())
>>>>>>>>> sum += value;
>>>>>>>>>
>>>>>>>>> Assuming no changes to the model, the sum will be 100. Now, assume
>>>>>>>>> that
>>>>>>>>> when the above loop is on index 2 (sum will be 30), that some other
>>>>>>>>> client
>>>>>>>>> changes the values to:
>>>>>>>>>
>>>>>>>>> 0: 20
>>>>>>>>> 1: 50
>>>>>>>>> 2: 10
>>>>>>>>> 3: 20
>>>>>>>>>
>>>>>>>>> will sum then end up being 60? That's really bad.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>>>>>> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It will be another list! :-) When we update, the client (during
>>>>>>>>>> the
>>>>>>>>>> iteration) will access suddenly the new list.
>>>>>>>>>> In that case!!!
>>>>>>>>>>
>>>>>>>>>> If you don't want to have passiveupdateenabled please call the
>>>>>>>>>> following:
>>>>>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>>>>>> see
>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> "Bryan
>>>>>>>
>>>>>>> Hunt"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> <bhunt@mac.com> a écrit dans le message de news:
>>>>>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> So, how does one deal with thread-safe issues. If in one thread
>>>>>>>>>>> I'm
>>>>>>>>>>> iterating over an EList, and in another thread CDO is updating
>>>>>>>>>>> that
>>>>>>>>>>> EList
>>>>>>>>>>> at the same time, I'll get a ConcurrentModificationException.
>>>>>>>>>>> How do
>>>>>>>>>>> you
>>>>>>>>>>> prevent that? Without some sort of locking mechanism, I fail to
>>>>>>>>>>> see how
>>>>>>>>>>> CDOView is of any use.
>>>>>>>>>>>
>>>>>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper <stepper@esc-net.de>
>>>>>>>>>>> said:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, but what happens when another client updates the model
>>>>>>>>>>>>> through a
>>>>>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>>>>>> The CDOView is, in this case, always seeing the latest state of
>>>>>>>>>>>> the
>>>>>>>>>>>> model.
>>>>>>>>>>>>
>>>>>>>>>>>> A variant is the special CDOAudit view which always looks at the
>>>>>>>>>>>> state
>>>>>>>>>>>> of
>>>>>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> /Eike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Bryan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper <stepper@esc-net.de>
>>>>>>>>>>>>> said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When a client uses a CDOView, how does the client access the
>>>>>>>>>>>>>>> model
>>>>>>>>>>>>>>> without the view updating the model while the client is
>>>>>>>>>>>>>>> accessing
>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A CDOView is always a read-only view to the model. You can't
>>>>>>>>>>>>>> modify
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> model through a CDOView. So in this sense it's always locked
>>>>>>>>>>>>>> ;-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>> /Eike
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>
>>>
>>>
>
>
>


Re: [CDO] Using CDOView? [message #423600 is a reply to message #423595] Thu, 02 October 2008 18:43 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020109060106030303060504
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Eike Stepper schrieb:
> Simon McDuff schrieb:
>> The CDORevision contained by CDOObject could be revised (Since
>> CDOSession control them).
>>
> Yes, that's the internal exception I meant ;-)
> But the client of a CDOView will not realize that directly (again with
> possible exception in very recent audit views, in which case this does
> not end in changed modeled state).
> It will rather notice it through the second effect of remote update:
> Switch of the associated revision to the current one. And I still
> think that protection against this is best provided through the CDOView.
After some browsing I think here is the best place:
CDOViewImpl.handleInvalidation()
And since we can't control the duration we have to wait for the lock I
suggest that we add a QueueWorker somewhere here in
CDOSessionImpl.notifyInvalidation():

| *for *(CDOViewImpl view : getViews())
{
*if *(view != excludedView)
{
*try*
{
view.handleInvalidation(timeStamp, dirtyOIDs, detachedObjects);
}
*catch *(RuntimeException ex)
{
OM.LOG.error(ex);
}
}
}|



>
> Am I wrong?
>
> Cheers
> /Eike
>
>> If you see no problem in that it should work.
>>
>> Simon
>>
>> "Eike Stepper" <stepper@esc-net.de> a


Re: [CDO] Using CDOView? [message #423603 is a reply to message #423580] Thu, 02 October 2008 19:25 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Bryan,

I just added this feature:

249536: Provide a public view lock to protect clients against remote
invalidation
https://bugs.eclipse.org/bugs/show_bug.cgi?id=249536

Please tell me if it works for you.

Cheers
/Eike


Bryan Hunt schrieb:
> On 2008-10-02 01:17:14 -0500, Eike Stepper <stepper@esc-net.de> said:
>
>> Simon McDuff schrieb:
>>> PassiveUpdatePolicy
>>> - NONE
>>> - NOTIFY
>>> - NOTIFYANDUPDATE
>>>
>>> Default will be NOTIFYANDUPDATE.
>>>
>> I'm not sure if this would really help in Bryan's particular case.
>> Would NOTIFY include a CDOEvent.INVALIDATE?
>> In this case the object would be in CDOState.PROXY and Bryan's
>> next loop access would actively update the object before returning
>> any data. The same effect as immediate passive update.
>>
>> I have two additional ideas that we could discusss:
>>
>> 1) PassiveUpdatePolicy
>>
>> - NONE
>> - NOTIFY
>> - UPDATE
>> - BATCH (means no change in network protocol but local buffering
>> until the policy is changed back to "normal")
>>
>> 2) Explicit Locking
>> - Either on CDOObject level (probably prone to deadlocks caused by
>> wrong lock ordering)
>> - or better on CDOView level (I prefer this variant. The framework
>> would lock the whole view during remote updates and the client can
>> decide if he needs to protect non-atomic operations or not)
>
> I think adding a lock() and unlock() to CDOView would be preferred in
> my case. I have a model that is based on a composite pattern which
> allows a user to construct a tree structure. When the model is saved,
> a server needs to see the new model. The server does not care about
> the individual updates to the model since it must walk the entire tree
> in one pass of the algorithm. The server walks the tree periodically
> (possibly as often as once per second) and while it is walking the
> tree, the model, obviously, cannot change. It therefore seems the
> easiest thing for me to do is:
>
> while(true)
> {
> view.lock();
> processModel();
> view.unlock();
> sleep(time);
> }
>
> If this is something you find worthy of inclusion in CDO, could this
> go in soon (ie, next couple of days), or are there other high priority
> items ahead of it? I think I might try using CDOAudit as a workaround.
>
> Thanks for taking the time to help me understand CDO.
>
> Bryan
>
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>>> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de
>>> news: gc11ls$img$1@build.eclipse.org...
>>>
>>>> Good question Bryan!!
>>>>
>>>> If you want to know when a specific object is updated you can do
>>>> the following:
>>>>
>>>> - Change Subscription Feature - It will gave you the delta.
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>
>
> When
>>>>
>>>> passiveupdate is at false, the only way to have notification is
>>>> change subscription.
>>>> The pros : It has delta changes.
>>>> The cons: Need to add an adapter for every objects.
>>>>
>>>> After that you can call session.refresh() to refresh your objects.
>>>> To keep the integrity of the graph you need to refresh every object
>>>> in your cache, you cannot refresh only one item.
>>>>
>>>> We also had an idea to have all invalidate notification (without
>>>> any subscription) without updating the object. It will not say what
>>>> changes for a specific object but it has been changed.
>>>> So maybe in that case, passiveUpdate should be a Policy instead of
>>>> a boolean value. What you think Eike ?
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>> gc101b$paq$1@build.eclipse.org...
>>>>
>>>>> Ok, if I use passiveUpdateEnabled(false), how do find out if there
>>>>> are updates to the model, and how do I get the model updated after
>>>>> I've finished processing?
>>>>>
>>>>> Bryan
>>>>>
>>>>> On 2008-10-01 17:14:48 -0500, "Simon McDuff" <smcduff@hotmail.com>
>>>>> said:
>>>>>
>>>>>
>>>>>> I'm not sure at 100%. Maybe I'm forgetting something.
>>>>>>
>>>>>> But yes I think you will get that result.
>>>>>>
>>>>>> Usually the mechanism is used not to calculate critical things.
>>>>>> As an
>>>>>> example, from the user interface you will receives notifications
>>>>>> as well so
>>>>>> you can update your interface.. etc..
>>>>>> For the processing or to calculate critical things, I think to be
>>>>>> safe you
>>>>>> should use passiveUpdateEnabled(false).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Bryan Hunt" <bhunt@mac.com> a écrit dans le message de news:
>>>>>> gc0sbg$mbv$1@build.eclipse.org...
>>>>>>
>>>>>>> So, if I understand this correctly, if I have an object that
>>>>>>> contains a
>>>>>>> list of index : integer with the following values:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 10
>>>>>>> 2: 50
>>>>>>> 3: 20
>>>>>>>
>>>>>>> Now imagine that I have the following loop:
>>>>>>>
>>>>>>> int sum = 0;
>>>>>>>
>>>>>>> for(int value : object.getValues())
>>>>>>> sum += value;
>>>>>>>
>>>>>>> Assuming no changes to the model, the sum will be 100. Now,
>>>>>>> assume that
>>>>>>> when the above loop is on index 2 (sum will be 30), that some
>>>>>>> other client
>>>>>>> changes the values to:
>>>>>>>
>>>>>>> 0: 20
>>>>>>> 1: 50
>>>>>>> 2: 10
>>>>>>> 3: 20
>>>>>>>
>>>>>>> will sum then end up being 60? That's really bad.
>>>>>>>
>>>>>>>
>>>>>>> On 2008-10-01 15:41:42 -0500, "Simon McDuff"
>>>>>>> <smcduff@hotmail.com> said:
>>>>>>>
>>>>>>>
>>>>>>>> It will be another list! :-) When we update, the client (during
>>>>>>>> the
>>>>>>>> iteration) will access suddenly the new list.
>>>>>>>> In that case!!!
>>>>>>>>
>>>>>>>> If you don't want to have passiveupdateenabled please call the
>>>>>>>> following:
>>>>>>>> session.setPassiveUpdateEnabled(false);
>>>>>>>> see
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?rev ision=1.7&root=Modeling_Project
>>>>>>>>
>
> "Bryan
>
> Hunt"
>
> <bhunt@mac.com>
>>>>>>>>
>>>>>>>> a écrit dans le message de news:
>>>>>>>> gc0h6l$jt0$1@build.eclipse.org...
>>>>>>>>
>>>>>>>>> So, how does one deal with thread-safe issues. If in one
>>>>>>>>> thread I'm
>>>>>>>>> iterating over an EList, and in another thread CDO is updating
>>>>>>>>> that
>>>>>>>>> EList
>>>>>>>>> at the same time, I'll get a ConcurrentModificationException.
>>>>>>>>> How do
>>>>>>>>> you
>>>>>>>>> prevent that? Without some sort of locking mechanism, I fail
>>>>>>>>> to see how
>>>>>>>>> CDOView is of any use.
>>>>>>>>>
>>>>>>>>> On 2008-10-01 13:52:47 -0500, Eike Stepper
>>>>>>>>> <stepper@esc-net.de> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>
>>>>>>>>>>> Ok, but what happens when another client updates the model
>>>>>>>>>>> through a
>>>>>>>>>>> transaction? Isn't the view updated with the latest model?
>>>>>>>>>>>
>>>>>>>>>> Yes, as long as the underlying session of the view has
>>>>>>>>>> PassiveUpdateEnabled, which is the default.
>>>>>>>>>> The CDOView is, in this case, always seeing the latest state
>>>>>>>>>> of the
>>>>>>>>>> model.
>>>>>>>>>>
>>>>>>>>>> A variant is the special CDOAudit view which always looks at
>>>>>>>>>> the state
>>>>>>>>>> of
>>>>>>>>>> a specified, fixed time. It's also read-only.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> /Eike
>>>>>>>>>>
>>>>>>>>>>> Bryan
>>>>>>>>>>>
>>>>>>>>>>> On 2008-10-01 13:49:08 -0500, Eike Stepper
>>>>>>>>>>> <stepper@esc-net.de> said:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Bryan Hunt schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>>> When a client uses a CDOView, how does the client access
>>>>>>>>>>>>> the model
>>>>>>>>>>>>> without the view updating the model while the client is
>>>>>>>>>>>>> accessing
>>>>>>>>>>>>> it?
>>>>>>>>>>>>> Is there a way to "lock" the view?
>>>>>>>>>>>>>
>>>>>>>>>>>> A CDOView is always a read-only view to the model. You
>>>>>>>>>>>> can't modify
>>>>>>>>>>>> the
>>>>>>>>>>>> model through a CDOView. So in this sense it's always
>>>>>>>>>>>> locked ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> /Eike
>>>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>


Previous Topic:How to obtain an EAttributes property name?
Next Topic:Eclipse/JUnit test works, Maven test fails...
Goto Forum:
  


Current Time: Thu Mar 28 08:44:51 GMT 2024

Powered by FUDForum. Page generated in 0.03681 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top