Re: attribute of EO not synced

[Ken Anderson]

Good question - I always that it was on the EO level, not attribute level.

> On Mar 21, 2018, at 8:03 PM, OC  wrote:
> 
> Ken,
> 
> On 22. 3. 2018, at 0:53, Ken Anderson  wrote:
> 
>> Are you sure no other attributes on the object were dirty in session B to 
>> block the update of the EO from the snapshot?
> 
> Actually, yes, pretty sure; for when B saves, _no_ update happens for the EO 
> 'foo'. Unless I am much mistaken, that must mean there were no dirty 
> attributes in foo at all, right?
> 
> (Aside of that, I have always thought that the attributes are merged 
> individually; i.e., that a dirtiness of attribute 'a' does not prevent 
> attribute 'b' (which is not dirty) being merged from the snapshot. Was I 
> wrong?)
> 
> Thanks a lot,
> OC
> 
>> 
>>> On Mar 21, 2018, at 7:41 PM, OC  wrote:
>>> 
>>> Hi there,
>>> 
>>> long time no see, my problems were plain and easy. Now though I am back 
>>> with another thing I can't understand.
>>> 
>>> There's an EO with a (string) attribute, let's say foo.value. A number of 
>>> sessions; session A occasionally sets the attribute, sessions B,C,D ... 
>>> read it. All happens in default ECs of sessions (not that it, far as I can 
>>> say, is important). Yesterday's log shows this sequence of events:
>>> 
>>> - A sets (and immediately saves to DB) foo.value "851;21.3.2018 10:48:19" 
>>> (lucky us, the value indeed happens to contain a timestamp)
>>> - B,C,D... all read (a number of times) proper foo.value "851;21.3.2018 
>>> 10:48:19"
>>> - A sets (and saves) foo.value "980;21.3.2018 10:51:07"
>>> - B reads (a number of times) OLD foo.value "851;21.3.2018 10:48:19" <- 
>>> this is the problem
>>> - whilst C,D,... all read proper foo.value "980;21.3.2018 10:51:07"
>>> - A sets (and saves) foo.value "1020;21.3.2018 10:52:20"
>>> - B,C,D... all read (a number of times) proper foo.value "1020;21.3.2018 
>>> 10:52:20"
>>> 
>>> Now, do please correct me if I am missing something, but I know of only two 
>>> cases which would explain the old foo.value in B:
>>> (i) the EC has not been unlocked and synced yet. Not the case: B did read 
>>> the wrong foo.value in a number of subsequent worker threads; besides, it 
>>> unlocks/locks the EC itself (more to that below);
>>> (ii) the foo.value in the EC of B is changed. Not the case either: B saves 
>>> changes in its EC a number of times; if the value has been changed in 
>>> there, it would get saved to the DB, which did not happen.
>>> 
>>> Is there any (iii) I have forgot?
>>> 
>>> Now, the code in which the value is read is somewhat non-standard; it needs 
>>> to ensure some level of serialisation, and thus looks like this:
>>> 
>>> ===
>>> EOEditingContext ec=... // the EC of objects we work with, happens to be 
>>> default EC of session here
>>> synchronized (lock) { // only one thread allowed to do this at the same time
>>> ec.unlock() // make sure all the changes from other threads ...
>>> ec.lock()   // ... are properly merged to our EC before we use it
>>> ...  // some other irrelevant code
>>> log "$foo.value" // here the attribute value read from our EO is logged 
>>> (the one which was wrong for B)
>>> ec.saveChanges() // changes made by the other irrelevant code are saved, if 
>>> any (it would save change of foo.value if any too)
>>> }
>>> ===
>>> 
>>> Note that the place where A does its foo.setValue(...); ec.saveChanges() is 
>>> *not* under the lock; there's no need (I believe) to make it serialized. 
>>> Only the “other irrelevant code” needs that.
>>> 
>>> About the only irregularity I has been able to find with the "980;21.3.2018 
>>> 10:51:07" was that it happened to been set whilst the session B did perform 
>>> its synchronized section. It well might have happened in paralel with the 
>>> “ec.unlock(); ec.lock()” part.
>>> 
>>> I wonder: might it perhaps be possible that, when one EC in a thread A does 
>>> “ec.unlock(); ec.lock()”, and another EC in another thread at the same time 
>>> changes (and saves) one of its EOs, that the change would NOT get properly 
>>> merged to the first EC?
>>> 
>>> If not, well, does anybody have any idea what might be the culprit?
>>> 
>>> Thanks a lot for any advice,
>>> OC
>>> 
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>>> 
>>> This email sent to kenli...@anderhome.com
>> 
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: attribute of EO not synced

[OC]

Ken,

On 22. 3. 2018, at 0:53, Ken Anderson  wrote:

> Are you sure no other attributes on the object were dirty in session B to 
> block the update of the EO from the snapshot?

Actually, yes, pretty sure; for when B saves, _no_ update happens for the EO 
'foo'. Unless I am much mistaken, that must mean there were no dirty attributes 
in foo at all, right?

(Aside of that, I have always thought that the attributes are merged 
individually; i.e., that a dirtiness of attribute 'a' does not prevent 
attribute 'b' (which is not dirty) being merged from the snapshot. Was I wrong?)

Thanks a lot,
OC

> 
>> On Mar 21, 2018, at 7:41 PM, OC  wrote:
>> 
>> Hi there,
>> 
>> long time no see, my problems were plain and easy. Now though I am back with 
>> another thing I can't understand.
>> 
>> There's an EO with a (string) attribute, let's say foo.value. A number of 
>> sessions; session A occasionally sets the attribute, sessions B,C,D ... read 
>> it. All happens in default ECs of sessions (not that it, far as I can say, 
>> is important). Yesterday's log shows this sequence of events:
>> 
>> - A sets (and immediately saves to DB) foo.value "851;21.3.2018 10:48:19" 
>> (lucky us, the value indeed happens to contain a timestamp)
>> - B,C,D... all read (a number of times) proper foo.value "851;21.3.2018 
>> 10:48:19"
>> - A sets (and saves) foo.value "980;21.3.2018 10:51:07"
>> - B reads (a number of times) OLD foo.value "851;21.3.2018 10:48:19" <- 
>> this is the problem
>> - whilst C,D,... all read proper foo.value "980;21.3.2018 10:51:07"
>> - A sets (and saves) foo.value "1020;21.3.2018 10:52:20"
>> - B,C,D... all read (a number of times) proper foo.value "1020;21.3.2018 
>> 10:52:20"
>> 
>> Now, do please correct me if I am missing something, but I know of only two 
>> cases which would explain the old foo.value in B:
>> (i) the EC has not been unlocked and synced yet. Not the case: B did read 
>> the wrong foo.value in a number of subsequent worker threads; besides, it 
>> unlocks/locks the EC itself (more to that below);
>> (ii) the foo.value in the EC of B is changed. Not the case either: B saves 
>> changes in its EC a number of times; if the value has been changed in there, 
>> it would get saved to the DB, which did not happen.
>> 
>> Is there any (iii) I have forgot?
>> 
>> Now, the code in which the value is read is somewhat non-standard; it needs 
>> to ensure some level of serialisation, and thus looks like this:
>> 
>> ===
>> EOEditingContext ec=... // the EC of objects we work with, happens to be 
>> default EC of session here
>> synchronized (lock) { // only one thread allowed to do this at the same time
>> ec.unlock() // make sure all the changes from other threads ...
>> ec.lock()   // ... are properly merged to our EC before we use it
>> ...  // some other irrelevant code
>> log "$foo.value" // here the attribute value read from our EO is logged (the 
>> one which was wrong for B)
>> ec.saveChanges() // changes made by the other irrelevant code are saved, if 
>> any (it would save change of foo.value if any too)
>> }
>> ===
>> 
>> Note that the place where A does its foo.setValue(...); ec.saveChanges() is 
>> *not* under the lock; there's no need (I believe) to make it serialized. 
>> Only the “other irrelevant code” needs that.
>> 
>> About the only irregularity I has been able to find with the "980;21.3.2018 
>> 10:51:07" was that it happened to been set whilst the session B did perform 
>> its synchronized section. It well might have happened in paralel with the 
>> “ec.unlock(); ec.lock()” part.
>> 
>> I wonder: might it perhaps be possible that, when one EC in a thread A does 
>> “ec.unlock(); ec.lock()”, and another EC in another thread at the same time 
>> changes (and saves) one of its EOs, that the change would NOT get properly 
>> merged to the first EC?
>> 
>> If not, well, does anybody have any idea what might be the culprit?
>> 
>> Thanks a lot for any advice,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>> 
>> This email sent to kenli...@anderhome.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: attribute of EO not synced

[Ken Anderson]

Are you sure no other attributes on the object were dirty in session B to block 
the update of the EO from the snapshot?

> On Mar 21, 2018, at 7:41 PM, OC  wrote:
> 
> Hi there,
> 
> long time no see, my problems were plain and easy. Now though I am back with 
> another thing I can't understand.
> 
> There's an EO with a (string) attribute, let's say foo.value. A number of 
> sessions; session A occasionally sets the attribute, sessions B,C,D ... read 
> it. All happens in default ECs of sessions (not that it, far as I can say, is 
> important). Yesterday's log shows this sequence of events:
> 
> - A sets (and immediately saves to DB) foo.value "851;21.3.2018 10:48:19" 
> (lucky us, the value indeed happens to contain a timestamp)
> - B,C,D... all read (a number of times) proper foo.value "851;21.3.2018 
> 10:48:19"
> - A sets (and saves) foo.value "980;21.3.2018 10:51:07"
> - B reads (a number of times) OLD foo.value "851;21.3.2018 10:48:19" <- 
> this is the problem
> - whilst C,D,... all read proper foo.value "980;21.3.2018 10:51:07"
> - A sets (and saves) foo.value "1020;21.3.2018 10:52:20"
> - B,C,D... all read (a number of times) proper foo.value "1020;21.3.2018 
> 10:52:20"
> 
> Now, do please correct me if I am missing something, but I know of only two 
> cases which would explain the old foo.value in B:
> (i) the EC has not been unlocked and synced yet. Not the case: B did read the 
> wrong foo.value in a number of subsequent worker threads; besides, it 
> unlocks/locks the EC itself (more to that below);
> (ii) the foo.value in the EC of B is changed. Not the case either: B saves 
> changes in its EC a number of times; if the value has been changed in there, 
> it would get saved to the DB, which did not happen.
> 
> Is there any (iii) I have forgot?
> 
> Now, the code in which the value is read is somewhat non-standard; it needs 
> to ensure some level of serialisation, and thus looks like this:
> 
> ===
> EOEditingContext ec=... // the EC of objects we work with, happens to be 
> default EC of session here
> synchronized (lock) { // only one thread allowed to do this at the same time
>  ec.unlock() // make sure all the changes from other threads ...
>  ec.lock()   // ... are properly merged to our EC before we use it
>  ...  // some other irrelevant code
>  log "$foo.value" // here the attribute value read from our EO is logged (the 
> one which was wrong for B)
>  ec.saveChanges() // changes made by the other irrelevant code are saved, if 
> any (it would save change of foo.value if any too)
> }
> ===
> 
> Note that the place where A does its foo.setValue(...); ec.saveChanges() is 
> *not* under the lock; there's no need (I believe) to make it serialized. Only 
> the “other irrelevant code” needs that.
> 
> About the only irregularity I has been able to find with the "980;21.3.2018 
> 10:51:07" was that it happened to been set whilst the session B did perform 
> its synchronized section. It well might have happened in paralel with the 
> “ec.unlock(); ec.lock()” part.
> 
> I wonder: might it perhaps be possible that, when one EC in a thread A does 
> “ec.unlock(); ec.lock()”, and another EC in another thread at the same time 
> changes (and saves) one of its EOs, that the change would NOT get properly 
> merged to the first EC?
> 
> If not, well, does anybody have any idea what might be the culprit?
> 
> Thanks a lot for any advice,
> OC
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
> 
> This email sent to kenli...@anderhome.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

attribute of EO not synced

[OC]

Hi there,

long time no see, my problems were plain and easy. Now though I am back with 
another thing I can't understand.

There's an EO with a (string) attribute, let's say foo.value. A number of 
sessions; session A occasionally sets the attribute, sessions B,C,D ... read 
it. All happens in default ECs of sessions (not that it, far as I can say, is 
important). Yesterday's log shows this sequence of events:

- A sets (and immediately saves to DB) foo.value "851;21.3.2018 10:48:19" 
(lucky us, the value indeed happens to contain a timestamp)
- B,C,D... all read (a number of times) proper foo.value "851;21.3.2018 
10:48:19"
- A sets (and saves) foo.value "980;21.3.2018 10:51:07"
- B reads (a number of times) OLD foo.value "851;21.3.2018 10:48:19" <- 
this is the problem
- whilst C,D,... all read proper foo.value "980;21.3.2018 10:51:07"
- A sets (and saves) foo.value "1020;21.3.2018 10:52:20"
- B,C,D... all read (a number of times) proper foo.value "1020;21.3.2018 
10:52:20"

Now, do please correct me if I am missing something, but I know of only two 
cases which would explain the old foo.value in B:
(i) the EC has not been unlocked and synced yet. Not the case: B did read the 
wrong foo.value in a number of subsequent worker threads; besides, it 
unlocks/locks the EC itself (more to that below);
(ii) the foo.value in the EC of B is changed. Not the case either: B saves 
changes in its EC a number of times; if the value has been changed in there, it 
would get saved to the DB, which did not happen.

Is there any (iii) I have forgot?

Now, the code in which the value is read is somewhat non-standard; it needs to 
ensure some level of serialisation, and thus looks like this:

===
EOEditingContext ec=... // the EC of objects we work with, happens to be 
default EC of session here
synchronized (lock) { // only one thread allowed to do this at the same time
  ec.unlock() // make sure all the changes from other threads ...
  ec.lock()   // ... are properly merged to our EC before we use it
  ...  // some other irrelevant code
  log "$foo.value" // here the attribute value read from our EO is logged (the 
one which was wrong for B)
  ec.saveChanges() // changes made by the other irrelevant code are saved, if 
any (it would save change of foo.value if any too)
}
===

Note that the place where A does its foo.setValue(...); ec.saveChanges() is 
*not* under the lock; there's no need (I believe) to make it serialized. Only 
the “other irrelevant code” needs that.

About the only irregularity I has been able to find with the "980;21.3.2018 
10:51:07" was that it happened to been set whilst the session B did perform its 
synchronized section. It well might have happened in paralel with the 
“ec.unlock(); ec.lock()” part.

I wonder: might it perhaps be possible that, when one EC in a thread A does 
“ec.unlock(); ec.lock()”, and another EC in another thread at the same time 
changes (and saves) one of its EOs, that the change would NOT get properly 
merged to the first EC?

If not, well, does anybody have any idea what might be the culprit?

Thanks a lot for any advice,
OC
 
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: D2W

[Theodore Petrosky]

Emre,

First, anything is possible!!!

In PW, a create page is ERMODWizardCreationPage. If you look in Project Wonder, 
you will find the source for this page in ERModernLook. Examine this 
carefully!! This is your documentation.

Look at this source!!! you will see how the buttons that are there are created! 
You will see the different booleans that are used to turn the button on and off.

There have been times when I want to add something to a template that doesn’t 
exist.  I clone the template (in this case ERMODWizardCreationPage cloning it 
into TPMODWizardCreationPage) and add what I want to this new page. Then create 
a rule that uses my new page as the creation page for this situation.

100 : pageConfiguration = ‘' => 
templateNameForWizardCreationPage = "TPMODWizardCreationPage" [Assignment]

Use the source as a guide. I am not saying this is the only way, but it has 
worked for me.

Ted

> On Mar 21, 2018, at 10:40 AM, e...@hacilar.ch wrote:
> 
> Yes I'm working with Project Wonder on a D2W Application. On the 
> PageConfigurations Edit and Create
> there are 2 Buttons on the Bottom.
> I need to add some additional functionality to those Buttons. Do you know if 
> this is possible?
> 
> Am 21.03.2018 15:24, schrieb Theodore Petrosky:
>> are you using Project Wonder? The way you word your question makes me
>> think you are not using Wonder.
>> Ted
>>> On Mar 21, 2018, at 10:14 AM, e...@hacilar.ch wrote:
>>> Hi Theodore
>>> For Example on a Create, on the Bottom of the Page there are 2 Buttons from 
>>> D2W.
>>> Once the Cancel Button, and once the Save Button.
>>> I need to access those Buttons, to do my custom stuff.
>>> Emre

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: D2W

[emre]

Yes I'm working with Project Wonder on a D2W Application. On the 
PageConfigurations Edit and Create

there are 2 Buttons on the Bottom.
I need to add some additional functionality to those Buttons. Do you 
know if this is possible?


Am 21.03.2018 15:24, schrieb Theodore Petrosky:

are you using Project Wonder? The way you word your question makes me
think you are not using Wonder.

Ted



On Mar 21, 2018, at 10:14 AM, e...@hacilar.ch wrote:

Hi Theodore

For Example on a Create, on the Bottom of the Page there are 2 Buttons 
from D2W.

Once the Cancel Button, and once the Save Button.
I need to access those Buttons, to do my custom stuff.

Emre

___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

D2W access PageButton

[emre]

Hi all,

I am currently working on a FileUpload in D2W and need to access to the 
PageButtons, so I can do my custom work, like cleaning up the directory 
on a Cancel. How exactly can I access those PageButtons?


Thanks in advance.

Emre Hacilar
e...@hacilar.ch
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com