Home » Modeling » EMF » [CDO] Using CDOView?
| | |
Re: [CDO] Using CDOView? [message #423526 is a reply to message #423525] |
Wed, 01 October 2008 18:52 |
|
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
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Using CDOView? [message #423527 is a reply to message #423526] |
Wed, 01 October 2008 18:57 |
Bryan Hunt 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 #423539 is a reply to message #423534] |
Wed, 01 October 2008 22:07 |
Bryan Hunt 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 #423541 is a reply to message #423540] |
Wed, 01 October 2008 23:10 |
Bryan Hunt 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 #423549 is a reply to message #423543] |
Thu, 02 October 2008 06:17 |
|
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
>>>>>>>>>>
>>>
>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] Using CDOView? [message #423580 is a reply to message #423549] |
Thu, 02 October 2008 14:50 |
Bryan Hunt 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 #423591 is a reply to message #423584] |
Thu, 02 October 2008 17:49 |
|
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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Using CDOView? [message #423592 is a reply to message #423580] |
Thu, 02 October 2008 18:03 |
|
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
>>>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] Using CDOView? [message #423595 is a reply to message #423593] |
Thu, 02 October 2008 18:22 |
|
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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>
>>>
>>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Using CDOView? [message #423600 is a reply to message #423595] |
Thu, 02 October 2008 18:43 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Using CDOView? [message #423603 is a reply to message #423580] |
Thu, 02 October 2008 19:25 |
|
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
>>>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Sep 26 05:26:12 GMT 2024
Powered by FUDForum. Page generated in 0.06010 seconds
|