Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO 0.8.0] Transaction/Objects scope
|
| Re: [CDO 0.8.0] Transaction/Objects scope [message #122088 is a reply to message #122037] |
Wed, 07 May 2008 07:27   |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
| Re: [CDO 0.8.0] Transaction/Objects scope [message #122154 is a reply to message #122116] |
Wed, 07 May 2008 08:59 |
|
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
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO 0.8.0] Transaction/Objects scope [message #122180 is a reply to message #122167] |
Wed, 07 May 2008 11:05 |
|
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
>>>>
>>>>
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO 0.8.0] Transaction/Objects scope [message #618010 is a reply to message #122037] |
Wed, 07 May 2008 07:27 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
| Re: [CDO 0.8.0] Transaction/Objects scope [message #618015 is a reply to message #122116] |
Wed, 07 May 2008 08:59 |
|
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
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO 0.8.0] Transaction/Objects scope [message #618017 is a reply to message #122167] |
Wed, 07 May 2008 11:05 |
|
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
>>>>
>>>>
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:12:00 GMT 2024
Powered by FUDForum. Page generated in 0.04333 seconds |
] 
Search
Help
Register
Login
Home
