Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO 0.8.0] Transaction/Objects scope
[CDO 0.8.0] Transaction/Objects scope [message #122037] Wed, 07 May 2008 01:11 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Eike,

I have a design question for you about the scope that have a CDOViewImpl and
CDOSessionImpl.

Let say I have transactionA (From sessionA) and transactionB (from
sessionB).

Both of them have objectA in their view.

In transactionA, I modify and commit objectA.
At commit time, TransactionB will invalidate objectA.

This is the current design. (correct me if I`m wrong).
The problem I would like to have a type of Transaction that do not
invalidate my objects.

What about the scope of a transaction. Usually, until I do refresh I should
not have a process modying the value that I`m accessing.

This is another example where it failed.
If we take the same example and objectA have a chunked collection of 1000
items. The chunked number is set at 10.
TransactionB fetch objectA and the first 10 items(out of 1000) of its
collection.
TransactionA invalidate objectA (in transactionB).
My application will fail since I cannot access my item from 11 to 1000
because my objects isn`t the same anymore... and I do not know if the
collection is still valid. This is a big problem.

Maybe if the pushing mechanism could be turn off it should be great or it
should be another kind of CDOView ?

What I expect is the following :

The client should control more the scope of a transaction that happen in the
server side.
Command like the following :
begin();
sync();
refresh();

The mode I would like to have is the following :
Once you fetch objects on the client... they are still valid until I commit
or refresh or begin a new transaction. Others transaction cannot invalidate
my objects and if I fetch a part of it, I can fetch the other part later
wihout having exception like currently and even if others transaction
modified it.

In my implementation with OO, 1 CDOTransaction == 1 Objectivity Transaction.
So objects are still valid until the client do a refresh, begin or commit.
But when I run the test cases... only once testcase fail.
InvalidationTest.testSeparateSession

I cannot fix it, since in my case I don`t want to behave like this testcase.


What do you think ? Is this go against your design ? Is it out of scope
from CDO perspective ?

Simon
Re: [CDO 0.8.0] Transaction/Objects scope [message #122088 is a reply to message #122037] Wed, 07 May 2008 07:27 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Simon,

I'd say the behaviour is what I expect of a distributed shared model, so
yes, this is by design. That said, we can also add a switch to completely
turn off the invalidation notifications from the server. Generally this is
a setting in the scope of a session. The session acts as a memory store
that mirrors the state of the repository as needed. When creating a
session we could offer a notification switch. Later, notification could
also be switched off, but not on. Maybe we could give the new sync()
method an optional notification switch to make it possible to switch it on
again. What do you think?

If there's a problem with chunked collections in the current design it
might be a bug. If you think so, please open a Bugzilla.

Cheers
/Eike


Simon McDuff wrote:

> Hi Eike,

> I have a design question for you about the scope that have a CDOViewImpl and
> CDOSessionImpl.

> Let say I have transactionA (From sessionA) and transactionB (from
> sessionB).

> Both of them have objectA in their view.

> In transactionA, I modify and commit objectA.
> At commit time, TransactionB will invalidate objectA.

> This is the current design. (correct me if I`m wrong).
> The problem I would like to have a type of Transaction that do not
> invalidate my objects.

> What about the scope of a transaction. Usually, until I do refresh I should
> not have a process modying the value that I`m accessing.

> This is another example where it failed.
> If we take the same example and objectA have a chunked collection of 1000
> items. The chunked number is set at 10.
> TransactionB fetch objectA and the first 10 items(out of 1000) of its
> collection.
> TransactionA invalidate objectA (in transactionB).
> My application will fail since I cannot access my item from 11 to 1000
> because my objects isn`t the same anymore... and I do not know if the
> collection is still valid. This is a big problem.

> Maybe if the pushing mechanism could be turn off it should be great or it
> should be another kind of CDOView ?

> What I expect is the following :

> The client should control more the scope of a transaction that happen in the
> server side.
> Command like the following :
> begin();
> sync();
> refresh();

> The mode I would like to have is the following :
> Once you fetch objects on the client... they are still valid until I commit
> or refresh or begin a new transaction. Others transaction cannot invalidate
> my objects and if I fetch a part of it, I can fetch the other part later
> wihout having exception like currently and even if others transaction
> modified it.

> In my implementation with OO, 1 CDOTransaction == 1 Objectivity Transaction.
> So objects are still valid until the client do a refresh, begin or commit.
> But when I run the test cases... only once testcase fail.
> InvalidationTest.testSeparateSession

> I cannot fix it, since in my case I don`t want to behave like this testcase.


> What do you think ? Is this go against your design ? Is it out of scope
> from CDO perspective ?

> Simon


Re: [CDO 0.8.0] Transaction/Objects scope [message #122116 is a reply to message #122088] Wed, 07 May 2008 07:41 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 0.8.0] Transaction/Objects scope [message #122129 is a reply to message #122088] Wed, 07 May 2008 08:18 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Finally I added a testcase :-)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=230832

"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO 0.8.0] Transaction/Objects scope [message #122154 is a reply to message #122116] Wed, 07 May 2008 08:59 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff wrote:


> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> 5df54df011f8c8c2de86b1049ee4cbac$1@www.eclipse.org...
>> Hi Simon,
>>
>> I'd say the behaviour is what I expect of a distributed shared model, so
>> yes, this is by design. That said, we can also add a switch to completely
>> turn off the invalidation notifications from the server. Generally this is
>> a setting in the scope of a session. The session acts as a memory store
>> that mirrors the state of the repository as needed. When creating a
>> session we could offer a notification switch. Later, notification could
>> also be switched off, but not on.
> Why not on ?

Because once the remote invalidation was switched off the state of the
local session could diverge from the state of the repository and simply
switching remote invalidation on again would not resend invalidations that
would have occured in the meantime while the switch was off. Simply
switching invalidations on would make the user believe that his session is
in sync with the server but that would not be true in general. If we
combine switching invalidations on while processing a sync() method call
the user could be sure to be in sync and stay in sync.


> Maybe we could give the new sync()
>> method an optional notification switch to make it possible to switch it on
>> again. What do you think?

> I would like to see something like. CDOViewImpl.enableInvalidation.

As I said, this would have to be a property of the session, not a
particular view. If one needs to have 2 views/transactions with different
invalidation settings one would have to use different sessions for that.

> We could transfer this value to the server. So View class on the server
> could have an attribute like the following
> View.enableInvalidation.

> Before sending data from Server to client we could verify that value is turn
> on. We could turn it on and off all the time. We will not send the data to
> the clients for nothing!

That's what I think (except for the session/view misalignment).


> We also need more than a switch, the back-end need to still have access to
> the version that are not the current. This is the responsability of the
> Store not the RevisionManager.

Could you please explain in more detail what you mean here?



>> If there's a problem with chunked collections in the current design it
>> might be a bug. If you think so, please open a Bugzilla.

> This is a bug.. but not with the implementation but rather with the design.
> (That I`ve made)
> The feature (chunked collection) needs object to be downloadable in part for
> a specific version. With the current CDO design, it is the responsability of
> the Store to achieve that but without transaction control... it is hard. To
> have this capability, client will need to control the scope of their
> transaction (begin, sync, commit, etc.)

To be honest, I have currently no clue how loading (even if in chunked
mode) relates to transaction scope/control. I fear I need more info...


> Maybe it is a good idea to start to put that feature in extended stuff ? Or
> you want it to be in the core ?

I think it depends. If it's new stuff and you're not yet a committer it
could be more convenient for you to separate it until it gets merged. If
it's a bug in the existing code (design) it should go directly into that
code.

BTW. I renamed your other bug and turned it into a feature request. You
should file another bug for the chunking issue and explain there why you
think there's a bug.

Cheers
/Eike



> Simon

>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff wrote:
>>
>>> Hi Eike,
>>
>>> I have a design question for you about the scope that have a CDOViewImpl
>>> and CDOSessionImpl.
>>
>>> Let say I have transactionA (From sessionA) and transactionB (from
>>> sessionB).
>>
>>> Both of them have objectA in their view.
>>
>>> In transactionA, I modify and commit objectA.
>>> At commit time, TransactionB will invalidate objectA.
>>
>>> This is the current design. (correct me if I`m wrong).
>>> The problem I would like to have a type of Transaction that do not
>>> invalidate my objects.
>>
>>> What about the scope of a transaction. Usually, until I do refresh I
>>> should not have a process modying the value that I`m accessing.
>>
>>> This is another example where it failed.
>>> If we take the same example and objectA have a chunked collection of 1000
>>> items. The chunked number is set at 10.
>>> TransactionB fetch objectA and the first 10 items(out of 1000) of its
>>> collection.
>>> TransactionA invalidate objectA (in transactionB).
>>> My application will fail since I cannot access my item from 11 to 1000
>>> because my objects isn`t the same anymore... and I do not know if the
>>> collection is still valid. This is a big problem.
>>
>>> Maybe if the pushing mechanism could be turn off it should be great or it
>>> should be another kind of CDOView ?
>>
>>> What I expect is the following :
>>
>>> The client should control more the scope of a transaction that happen in
>>> the server side.
>>> Command like the following :
>>> begin();
>>> sync();
>>> refresh();
>>
>>> The mode I would like to have is the following :
>>> Once you fetch objects on the client... they are still valid until I
>>> commit or refresh or begin a new transaction. Others transaction cannot
>>> invalidate my objects and if I fetch a part of it, I can fetch the other
>>> part later wihout having exception like currently and even if others
>>> transaction modified it.
>>
>>> In my implementation with OO, 1 CDOTransaction == 1 Objectivity
>>> Transaction. So objects are still valid until the client do a refresh,
>>> begin or commit. But when I run the test cases... only once testcase
>>> fail.
>>> InvalidationTest.testSeparateSession
>>
>>> I cannot fix it, since in my case I don`t want to behave like this
>>> testcase.
>>
>>
>>> What do you think ? Is this go against your design ? Is it out of scope
>>> from CDO perspective ?
>>
>>> Simon
>>
>>


Re: [CDO 0.8.0] Transaction/Objects scope [message #122167 is a reply to message #122154] Wed, 07 May 2008 09:24 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Let me me if this behavior is expected or not.

1- When I go through a collection, it could failed because my collection
received an invalidate notification.
2 - When I go through a collection, I could iterate through a list that is
invalid. The client will go through it without knowing it is invalid. It
will display the collection in a wrong way.

If this is an expected behavior... it is not a bug...

If this should not happen.. it is a bug in the design.

For my point a view, I don`t want to have this behavior in the case I
desactivate notification. In the case where we use notification on... it
will always happen.. we cannot do anything about it. (We should at least
through an exception)

If I understand correctly all cdotransaction from the same session should
have the same version of the revision. Correct ?
If this is the case, you are right we should apply this feature on the
CDOSession.

Basically we could have 2 mode :
- Automatic Sync
- Manual Sync

It is why I thought... we can turn on and off the notification !!! I`m happy
that we understand each other!! :-)

Simon



"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO 0.8.0] Transaction/Objects scope [message #122180 is a reply to message #122167] Wed, 07 May 2008 11:05 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff wrote:

> Let me me if this behavior is expected or not.

> 1- When I go through a collection, it could failed because my collection
> received an invalidate notification.
> 2 - When I go through a collection, I could iterate through a list that is
> invalid. The client will go through it without knowing it is invalid. It
> will display the collection in a wrong way.

> If this is an expected behavior... it is not a bug...

> If this should not happen.. it is a bug in the design.

> For my point a view, I don`t want to have this behavior in the case I
> desactivate notification.

Yes, with the new feature you requested (turn off invalidations) the
collection would be invalid WRT the remote state but the iteration should
not fail.

>In the case where we use notification on... it
> will always happen.. we cannot do anything about it. (We should at least
> through an exception)

I'd also vote for something like a ConcurrentModificationException (maybe
a subclass).


> If I understand correctly all cdotransaction from the same session should
> have the same version of the revision. Correct ?

Yes, with the exemption of revisions that were modified in a transaction.

> If this is the case, you are right we should apply this feature on the
> CDOSession.

Correct ;-)


> Basically we could have 2 mode :
> - Automatic Sync
> - Manual Sync

> It is why I thought... we can turn on and off the notification !!! I`m happy
> that we understand each other!! :-)

Yes, it's always nice!! hehe

Cheers
/Eike



> Simon



> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> 4d3099b17f8af7a57d0171ae61e24824$1@www.eclipse.org...
>> Simon McDuff wrote:
>>
>>
>>> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
>>> 5df54df011f8c8c2de86b1049ee4cbac$1@www.eclipse.org...
>>>> Hi Simon,
>>>>
>>>> I'd say the behaviour is what I expect of a distributed shared model, so
>>>> yes, this is by design. That said, we can also add a switch to
>>>> completely turn off the invalidation notifications from the server.
>>>> Generally this is a setting in the scope of a session. The session acts
>>>> as a memory store that mirrors the state of the repository as needed.
>>>> When creating a session we could offer a notification switch. Later,
>>>> notification could also be switched off, but not on.
>>> Why not on ?
>>
>> Because once the remote invalidation was switched off the state of the
>> local session could diverge from the state of the repository and simply
>> switching remote invalidation on again would not resend invalidations that
>> would have occured in the meantime while the switch was off. Simply
>> switching invalidations on would make the user believe that his session is
>> in sync with the server but that would not be true in general. If we
>> combine switching invalidations on while processing a sync() method call
>> the user could be sure to be in sync and stay in sync.
>>
>>
>>> Maybe we could give the new sync()
>>>> method an optional notification switch to make it possible to switch it
>>>> on again. What do you think?
>>
>>> I would like to see something like. CDOViewImpl.enableInvalidation.
>>
>> As I said, this would have to be a property of the session, not a
>> particular view. If one needs to have 2 views/transactions with different
>> invalidation settings one would have to use different sessions for that.
>>
>>> We could transfer this value to the server. So View class on the server
>>> could have an attribute like the following
>>> View.enableInvalidation.
>>
>>> Before sending data from Server to client we could verify that value is
>>> turn on. We could turn it on and off all the time. We will not send the
>>> data to the clients for nothing!
>>
>> That's what I think (except for the session/view misalignment).
>>
>>
>>> We also need more than a switch, the back-end need to still have access
>>> to the version that are not the current. This is the responsability of
>>> the Store not the RevisionManager.
>>
>> Could you please explain in more detail what you mean here?
>>
>>
>>
>>>> If there's a problem with chunked collections in the current design it
>>>> might be a bug. If you think so, please open a Bugzilla.
>>
>>> This is a bug.. but not with the implementation but rather with the
>>> design. (That I`ve made)
>>> The feature (chunked collection) needs object to be downloadable in part
>>> for a specific version. With the current CDO design, it is the
>>> responsability of the Store to achieve that but without transaction
>>> control... it is hard. To have this capability, client will need to
>>> control the scope of their transaction (begin, sync, commit, etc.)
>>
>> To be honest, I have currently no clue how loading (even if in chunked
>> mode) relates to transaction scope/control. I fear I need more info...
>>
>>
>>> Maybe it is a good idea to start to put that feature in extended stuff ?
>>> Or you want it to be in the core ?
>>
>> I think it depends. If it's new stuff and you're not yet a committer it
>> could be more convenient for you to separate it until it gets merged. If
>> it's a bug in the existing code (design) it should go directly into that
>> code.
>>
>> BTW. I renamed your other bug and turned it into a feature request. You
>> should file another bug for the chunking issue and explain there why you
>> think there's a bug.
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Simon
>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Simon McDuff wrote:
>>>>
>>>>> Hi Eike,
>>>>
>>>>> I have a design question for you about the scope that have a
>>>>> CDOViewImpl and CDOSessionImpl.
>>>>
>>>>> Let say I have transactionA (From sessionA) and transactionB (from
>>>>> sessionB).
>>>>
>>>>> Both of them have objectA in their view.
>>>>
>>>>> In transactionA, I modify and commit objectA.
>>>>> At commit time, TransactionB will invalidate objectA.
>>>>
>>>>> This is the current design. (correct me if I`m wrong).
>>>>> The problem I would like to have a type of Transaction that do not
>>>>> invalidate my objects.
>>>>
>>>>> What about the scope of a transaction. Usually, until I do refresh I
>>>>> should not have a process modying the value that I`m accessing.
>>>>
>>>>> This is another example where it failed.
>>>>> If we take the same example and objectA have a chunked collection of
>>>>> 1000 items. The chunked number is set at 10.
>>>>> TransactionB fetch objectA and the first 10 items(out of 1000) of its
>>>>> collection.
>>>>> TransactionA invalidate objectA (in transactionB).
>>>>> My application will fail since I cannot access my item from 11 to 1000
>>>>> because my objects isn`t the same anymore... and I do not know if the
>>>>> collection is still valid. This is a big problem.
>>>>
>>>>> Maybe if the pushing mechanism could be turn off it should be great or
>>>>> it should be another kind of CDOView ?
>>>>
>>>>> What I expect is the following :
>>>>
>>>>> The client should control more the scope of a transaction that happen
>>>>> in the server side.
>>>>> Command like the following :
>>>>> begin();
>>>>> sync();
>>>>> refresh();
>>>>
>>>>> The mode I would like to have is the following :
>>>>> Once you fetch objects on the client... they are still valid until I
>>>>> commit or refresh or begin a new transaction. Others transaction cannot
>>>>> invalidate my objects and if I fetch a part of it, I can fetch the
>>>>> other part later wihout having exception like currently and even if
>>>>> others transaction modified it.
>>>>
>>>>> In my implementation with OO, 1 CDOTransaction == 1 Objectivity
>>>>> Transaction. So objects are still valid until the client do a refresh,
>>>>> begin or commit. But when I run the test cases... only once testcase
>>>>> fail.
>>>>> InvalidationTest.testSeparateSession
>>>>
>>>>> I cannot fix it, since in my case I don`t want to behave like this
>>>>> testcase.
>>>>
>>>>
>>>>> What do you think ? Is this go against your design ? Is it out of
>>>>> scope from CDO perspective ?
>>>>
>>>>> Simon
>>>>
>>>>
>>
>>


Re: [CDO 0.8.0] Transaction/Objects scope [message #618010 is a reply to message #122037] Wed, 07 May 2008 07:27 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Simon,

I'd say the behaviour is what I expect of a distributed shared model, so
yes, this is by design. That said, we can also add a switch to completely
turn off the invalidation notifications from the server. Generally this is
a setting in the scope of a session. The session acts as a memory store
that mirrors the state of the repository as needed. When creating a
session we could offer a notification switch. Later, notification could
also be switched off, but not on. Maybe we could give the new sync()
method an optional notification switch to make it possible to switch it on
again. What do you think?

If there's a problem with chunked collections in the current design it
might be a bug. If you think so, please open a Bugzilla.

Cheers
/Eike


Simon McDuff wrote:

> Hi Eike,

> I have a design question for you about the scope that have a CDOViewImpl and
> CDOSessionImpl.

> Let say I have transactionA (From sessionA) and transactionB (from
> sessionB).

> Both of them have objectA in their view.

> In transactionA, I modify and commit objectA.
> At commit time, TransactionB will invalidate objectA.

> This is the current design. (correct me if I`m wrong).
> The problem I would like to have a type of Transaction that do not
> invalidate my objects.

> What about the scope of a transaction. Usually, until I do refresh I should
> not have a process modying the value that I`m accessing.

> This is another example where it failed.
> If we take the same example and objectA have a chunked collection of 1000
> items. The chunked number is set at 10.
> TransactionB fetch objectA and the first 10 items(out of 1000) of its
> collection.
> TransactionA invalidate objectA (in transactionB).
> My application will fail since I cannot access my item from 11 to 1000
> because my objects isn`t the same anymore... and I do not know if the
> collection is still valid. This is a big problem.

> Maybe if the pushing mechanism could be turn off it should be great or it
> should be another kind of CDOView ?

> What I expect is the following :

> The client should control more the scope of a transaction that happen in the
> server side.
> Command like the following :
> begin();
> sync();
> refresh();

> The mode I would like to have is the following :
> Once you fetch objects on the client... they are still valid until I commit
> or refresh or begin a new transaction. Others transaction cannot invalidate
> my objects and if I fetch a part of it, I can fetch the other part later
> wihout having exception like currently and even if others transaction
> modified it.

> In my implementation with OO, 1 CDOTransaction == 1 Objectivity Transaction.
> So objects are still valid until the client do a refresh, begin or commit.
> But when I run the test cases... only once testcase fail.
> InvalidationTest.testSeparateSession

> I cannot fix it, since in my case I don`t want to behave like this testcase.


> What do you think ? Is this go against your design ? Is it out of scope
> from CDO perspective ?

> Simon


Re: [CDO 0.8.0] Transaction/Objects scope [message #618012 is a reply to message #122088] Wed, 07 May 2008 07:41 Go to previous 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 0.8.0] Transaction/Objects scope [message #618013 is a reply to message #122088] Wed, 07 May 2008 08:18 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Finally I added a testcase :-)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=230832

"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO 0.8.0] Transaction/Objects scope [message #618015 is a reply to message #122116] Wed, 07 May 2008 08:59 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff wrote:


> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> 5df54df011f8c8c2de86b1049ee4cbac$1@www.eclipse.org...
>> Hi Simon,
>>
>> I'd say the behaviour is what I expect of a distributed shared model, so
>> yes, this is by design. That said, we can also add a switch to completely
>> turn off the invalidation notifications from the server. Generally this is
>> a setting in the scope of a session. The session acts as a memory store
>> that mirrors the state of the repository as needed. When creating a
>> session we could offer a notification switch. Later, notification could
>> also be switched off, but not on.
> Why not on ?

Because once the remote invalidation was switched off the state of the
local session could diverge from the state of the repository and simply
switching remote invalidation on again would not resend invalidations that
would have occured in the meantime while the switch was off. Simply
switching invalidations on would make the user believe that his session is
in sync with the server but that would not be true in general. If we
combine switching invalidations on while processing a sync() method call
the user could be sure to be in sync and stay in sync.


> Maybe we could give the new sync()
>> method an optional notification switch to make it possible to switch it on
>> again. What do you think?

> I would like to see something like. CDOViewImpl.enableInvalidation.

As I said, this would have to be a property of the session, not a
particular view. If one needs to have 2 views/transactions with different
invalidation settings one would have to use different sessions for that.

> We could transfer this value to the server. So View class on the server
> could have an attribute like the following
> View.enableInvalidation.

> Before sending data from Server to client we could verify that value is turn
> on. We could turn it on and off all the time. We will not send the data to
> the clients for nothing!

That's what I think (except for the session/view misalignment).


> We also need more than a switch, the back-end need to still have access to
> the version that are not the current. This is the responsability of the
> Store not the RevisionManager.

Could you please explain in more detail what you mean here?



>> If there's a problem with chunked collections in the current design it
>> might be a bug. If you think so, please open a Bugzilla.

> This is a bug.. but not with the implementation but rather with the design.
> (That I`ve made)
> The feature (chunked collection) needs object to be downloadable in part for
> a specific version. With the current CDO design, it is the responsability of
> the Store to achieve that but without transaction control... it is hard. To
> have this capability, client will need to control the scope of their
> transaction (begin, sync, commit, etc.)

To be honest, I have currently no clue how loading (even if in chunked
mode) relates to transaction scope/control. I fear I need more info...


> Maybe it is a good idea to start to put that feature in extended stuff ? Or
> you want it to be in the core ?

I think it depends. If it's new stuff and you're not yet a committer it
could be more convenient for you to separate it until it gets merged. If
it's a bug in the existing code (design) it should go directly into that
code.

BTW. I renamed your other bug and turned it into a feature request. You
should file another bug for the chunking issue and explain there why you
think there's a bug.

Cheers
/Eike



> Simon

>>
>> Cheers
>> /Eike
>>
>>
>> Simon McDuff wrote:
>>
>>> Hi Eike,
>>
>>> I have a design question for you about the scope that have a CDOViewImpl
>>> and CDOSessionImpl.
>>
>>> Let say I have transactionA (From sessionA) and transactionB (from
>>> sessionB).
>>
>>> Both of them have objectA in their view.
>>
>>> In transactionA, I modify and commit objectA.
>>> At commit time, TransactionB will invalidate objectA.
>>
>>> This is the current design. (correct me if I`m wrong).
>>> The problem I would like to have a type of Transaction that do not
>>> invalidate my objects.
>>
>>> What about the scope of a transaction. Usually, until I do refresh I
>>> should not have a process modying the value that I`m accessing.
>>
>>> This is another example where it failed.
>>> If we take the same example and objectA have a chunked collection of 1000
>>> items. The chunked number is set at 10.
>>> TransactionB fetch objectA and the first 10 items(out of 1000) of its
>>> collection.
>>> TransactionA invalidate objectA (in transactionB).
>>> My application will fail since I cannot access my item from 11 to 1000
>>> because my objects isn`t the same anymore... and I do not know if the
>>> collection is still valid. This is a big problem.
>>
>>> Maybe if the pushing mechanism could be turn off it should be great or it
>>> should be another kind of CDOView ?
>>
>>> What I expect is the following :
>>
>>> The client should control more the scope of a transaction that happen in
>>> the server side.
>>> Command like the following :
>>> begin();
>>> sync();
>>> refresh();
>>
>>> The mode I would like to have is the following :
>>> Once you fetch objects on the client... they are still valid until I
>>> commit or refresh or begin a new transaction. Others transaction cannot
>>> invalidate my objects and if I fetch a part of it, I can fetch the other
>>> part later wihout having exception like currently and even if others
>>> transaction modified it.
>>
>>> In my implementation with OO, 1 CDOTransaction == 1 Objectivity
>>> Transaction. So objects are still valid until the client do a refresh,
>>> begin or commit. But when I run the test cases... only once testcase
>>> fail.
>>> InvalidationTest.testSeparateSession
>>
>>> I cannot fix it, since in my case I don`t want to behave like this
>>> testcase.
>>
>>
>>> What do you think ? Is this go against your design ? Is it out of scope
>>> from CDO perspective ?
>>
>>> Simon
>>
>>


Re: [CDO 0.8.0] Transaction/Objects scope [message #618016 is a reply to message #122154] Wed, 07 May 2008 09:24 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Let me me if this behavior is expected or not.

1- When I go through a collection, it could failed because my collection
received an invalidate notification.
2 - When I go through a collection, I could iterate through a list that is
invalid. The client will go through it without knowing it is invalid. It
will display the collection in a wrong way.

If this is an expected behavior... it is not a bug...

If this should not happen.. it is a bug in the design.

For my point a view, I don`t want to have this behavior in the case I
desactivate notification. In the case where we use notification on... it
will always happen.. we cannot do anything about it. (We should at least
through an exception)

If I understand correctly all cdotransaction from the same session should
have the same version of the revision. Correct ?
If this is the case, you are right we should apply this feature on the
CDOSession.

Basically we could have 2 mode :
- Automatic Sync
- Manual Sync

It is why I thought... we can turn on and off the notification !!! I`m happy
that we understand each other!! :-)

Simon



"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO 0.8.0] Transaction/Objects scope [message #618017 is a reply to message #122167] Wed, 07 May 2008 11:05 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Simon McDuff wrote:

> Let me me if this behavior is expected or not.

> 1- When I go through a collection, it could failed because my collection
> received an invalidate notification.
> 2 - When I go through a collection, I could iterate through a list that is
> invalid. The client will go through it without knowing it is invalid. It
> will display the collection in a wrong way.

> If this is an expected behavior... it is not a bug...

> If this should not happen.. it is a bug in the design.

> For my point a view, I don`t want to have this behavior in the case I
> desactivate notification.

Yes, with the new feature you requested (turn off invalidations) the
collection would be invalid WRT the remote state but the iteration should
not fail.

>In the case where we use notification on... it
> will always happen.. we cannot do anything about it. (We should at least
> through an exception)

I'd also vote for something like a ConcurrentModificationException (maybe
a subclass).


> If I understand correctly all cdotransaction from the same session should
> have the same version of the revision. Correct ?

Yes, with the exemption of revisions that were modified in a transaction.

> If this is the case, you are right we should apply this feature on the
> CDOSession.

Correct ;-)


> Basically we could have 2 mode :
> - Automatic Sync
> - Manual Sync

> It is why I thought... we can turn on and off the notification !!! I`m happy
> that we understand each other!! :-)

Yes, it's always nice!! hehe

Cheers
/Eike



> Simon



> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> 4d3099b17f8af7a57d0171ae61e24824$1@www.eclipse.org...
>> Simon McDuff wrote:
>>
>>
>>> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
>>> 5df54df011f8c8c2de86b1049ee4cbac$1@www.eclipse.org...
>>>> Hi Simon,
>>>>
>>>> I'd say the behaviour is what I expect of a distributed shared model, so
>>>> yes, this is by design. That said, we can also add a switch to
>>>> completely turn off the invalidation notifications from the server.
>>>> Generally this is a setting in the scope of a session. The session acts
>>>> as a memory store that mirrors the state of the repository as needed.
>>>> When creating a session we could offer a notification switch. Later,
>>>> notification could also be switched off, but not on.
>>> Why not on ?
>>
>> Because once the remote invalidation was switched off the state of the
>> local session could diverge from the state of the repository and simply
>> switching remote invalidation on again would not resend invalidations that
>> would have occured in the meantime while the switch was off. Simply
>> switching invalidations on would make the user believe that his session is
>> in sync with the server but that would not be true in general. If we
>> combine switching invalidations on while processing a sync() method call
>> the user could be sure to be in sync and stay in sync.
>>
>>
>>> Maybe we could give the new sync()
>>>> method an optional notification switch to make it possible to switch it
>>>> on again. What do you think?
>>
>>> I would like to see something like. CDOViewImpl.enableInvalidation.
>>
>> As I said, this would have to be a property of the session, not a
>> particular view. If one needs to have 2 views/transactions with different
>> invalidation settings one would have to use different sessions for that.
>>
>>> We could transfer this value to the server. So View class on the server
>>> could have an attribute like the following
>>> View.enableInvalidation.
>>
>>> Before sending data from Server to client we could verify that value is
>>> turn on. We could turn it on and off all the time. We will not send the
>>> data to the clients for nothing!
>>
>> That's what I think (except for the session/view misalignment).
>>
>>
>>> We also need more than a switch, the back-end need to still have access
>>> to the version that are not the current. This is the responsability of
>>> the Store not the RevisionManager.
>>
>> Could you please explain in more detail what you mean here?
>>
>>
>>
>>>> If there's a problem with chunked collections in the current design it
>>>> might be a bug. If you think so, please open a Bugzilla.
>>
>>> This is a bug.. but not with the implementation but rather with the
>>> design. (That I`ve made)
>>> The feature (chunked collection) needs object to be downloadable in part
>>> for a specific version. With the current CDO design, it is the
>>> responsability of the Store to achieve that but without transaction
>>> control... it is hard. To have this capability, client will need to
>>> control the scope of their transaction (begin, sync, commit, etc.)
>>
>> To be honest, I have currently no clue how loading (even if in chunked
>> mode) relates to transaction scope/control. I fear I need more info...
>>
>>
>>> Maybe it is a good idea to start to put that feature in extended stuff ?
>>> Or you want it to be in the core ?
>>
>> I think it depends. If it's new stuff and you're not yet a committer it
>> could be more convenient for you to separate it until it gets merged. If
>> it's a bug in the existing code (design) it should go directly into that
>> code.
>>
>> BTW. I renamed your other bug and turned it into a feature request. You
>> should file another bug for the chunking issue and explain there why you
>> think there's a bug.
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Simon
>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Simon McDuff wrote:
>>>>
>>>>> Hi Eike,
>>>>
>>>>> I have a design question for you about the scope that have a
>>>>> CDOViewImpl and CDOSessionImpl.
>>>>
>>>>> Let say I have transactionA (From sessionA) and transactionB (from
>>>>> sessionB).
>>>>
>>>>> Both of them have objectA in their view.
>>>>
>>>>> In transactionA, I modify and commit objectA.
>>>>> At commit time, TransactionB will invalidate objectA.
>>>>
>>>>> This is the current design. (correct me if I`m wrong).
>>>>> The problem I would like to have a type of Transaction that do not
>>>>> invalidate my objects.
>>>>
>>>>> What about the scope of a transaction. Usually, until I do refresh I
>>>>> should not have a process modying the value that I`m accessing.
>>>>
>>>>> This is another example where it failed.
>>>>> If we take the same example and objectA have a chunked collection of
>>>>> 1000 items. The chunked number is set at 10.
>>>>> TransactionB fetch objectA and the first 10 items(out of 1000) of its
>>>>> collection.
>>>>> TransactionA invalidate objectA (in transactionB).
>>>>> My application will fail since I cannot access my item from 11 to 1000
>>>>> because my objects isn`t the same anymore... and I do not know if the
>>>>> collection is still valid. This is a big problem.
>>>>
>>>>> Maybe if the pushing mechanism could be turn off it should be great or
>>>>> it should be another kind of CDOView ?
>>>>
>>>>> What I expect is the following :
>>>>
>>>>> The client should control more the scope of a transaction that happen
>>>>> in the server side.
>>>>> Command like the following :
>>>>> begin();
>>>>> sync();
>>>>> refresh();
>>>>
>>>>> The mode I would like to have is the following :
>>>>> Once you fetch objects on the client... they are still valid until I
>>>>> commit or refresh or begin a new transaction. Others transaction cannot
>>>>> invalidate my objects and if I fetch a part of it, I can fetch the
>>>>> other part later wihout having exception like currently and even if
>>>>> others transaction modified it.
>>>>
>>>>> In my implementation with OO, 1 CDOTransaction == 1 Objectivity
>>>>> Transaction. So objects are still valid until the client do a refresh,
>>>>> begin or commit. But when I run the test cases... only once testcase
>>>>> fail.
>>>>> InvalidationTest.testSeparateSession
>>>>
>>>>> I cannot fix it, since in my case I don`t want to behave like this
>>>>> testcase.
>>>>
>>>>
>>>>> What do you think ? Is this go against your design ? Is it out of
>>>>> scope from CDO perspective ?
>>>>
>>>>> Simon
>>>>
>>>>
>>
>>


Previous Topic:[EMF Compare]MatchEngine NPE bug
Next Topic:Hibernate Settings in Teneo
Goto Forum:
  


Current Time: Wed Apr 01 21:11:16 GMT 2020

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

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

Back to the top