Re: updates to same value: why they happen?

2018-08-14 Thread ocs@ocs
Ha! Seems I have found the culprit. Thanks a lot for the advice

>> changing type between Integer and Long?

pursuing it further, it looks like the darned BigDecimal thing's equals work in 
a pretty weird way, considering exactly same values, just stored with a 
different scale, well, non-equal (this is actually documented suggesting using 
compareTo instead; but I bet EOF uses equals internally — it could hardly do 
otherwise —, and therefore same values are stored unnecessarily. Oh sigh.)

Thanks again!
OC


> On 14 Aug 2018, at 8:13 PM, ocs@ocs  wrote:
> 
> Chuck,
> 
>> On 14 Aug 2018, at 7:37 PM, Chuck Hill > > wrote:
>> 
>> Could there be some place in your code that is changing type between Integer 
>> and Long?  EOF would see that as a value change, though the value logged 
>> would appear the same.
> 
> thanks a lot, but actually I use BigDecimals for the attribute, and my 
> accessor methods look like this:
> 
> ===
>   public java.math.BigDecimal originalAmount() {
> return (java.math.BigDecimal) 
> storedValueForKey(_DBAuction.ORIGINAL_AMOUNT_KEY);
>   }
>   public java.math.BigDecimal getOriginalAmount() { originalAmount() }
>   public void setOriginalAmount(java.math.BigDecimal value) {
> takeStoredValueForKey(value, _DBAuction.ORIGINAL_AMOUNT_KEY);
>   }
> ===
> 
> given which I think it would not be the culprit, unless I am overlooking some 
> trick. Weird.
> 
> Let me please check whether I recall properly how the sync betw. EC and 
> snapshot works. Let's assume there's an enterprise object “eo” with an 
> attributes “foo“ and “bar“. Let's assume x.foo=="a" at the moment. Now
> 
> 1. user A starts a R/R loop and reads in eo to work with;
> 2. user B starts his own R/R loop, changes eo.foo to "b", savesChanges and 
> ends its R/R loop;
> 3. user A — still in the same R/R loop of 1 — now
> 
> 3a. makes some irrelevant changes without ever touching eo, and saves them. 
> Since eo did never got into his updated object list, it's all right;
> 
> 3b. he changes the eo.bar attribute (never changing eo.foo anyhow), and saves 
> changes.
> 
> In this case, oops! eo.foo gets rewritten in the database to the old value of 
> "a", for eo is amongst A's updated object list, and the live eo.a value 
> differs from the snapshot — A's live value of eo.a would have been updated 
> from snapshot at the end of the R/R loop, when EC unlocks; but that's in this 
> case too late.
> 
> Right, is this the behaviour, or am I overlooking something here?
> 
> Thanks again a very big lot,
> OC
> 
>>  
>> From: Webobjects-dev 
>> > > on 
>> behalf of "ocs@ocs" mailto:o...@ocs.cz>>
>> Date: Tuesday, August 14, 2018 at 10:26 AM
>> To: "webobjects-dev@lists.apple.com " 
>> mailto:webobjects-dev@lists.apple.com>>
>> Subject: updates to same value: why they happen?
>>  
>> Gentlemen, 
>>  
>> my code logs out all database changes in the 
>> databaseContextWillPerformAdaptorOperations delegate method.
>>  
>> Lately from these logs I have found that one of my applications tends to 
>> pretty often update an attribute to the same value it used to have before, 
>> like this:
>>  
>> ===
>> 249 /tmp> fgrep "UPDATE on 'DBAuction' ((uid = 1002533)" LOG
>> 13:38:25.214|WorkerThread7 - 4: UPDATE on 'DBAuction' ((uid = 1002533)) 
>> 1{originalAmount:11058}
>> 09:02:58.136|WorkerThread2 - 1: UPDATE on 'DBAuction' ((uid = 1002533)) 
>> 1{originalAmount:11058}
>> 09:55:57.970|WorkerThread5 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
>> 1{originalAmount:11058}
>> 10:09:37.079|WorkerThread22 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
>> 1{originalAmount:11058}
>> 10:14:31.399|WorkerThread11 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
>> 1{originalAmount:11058}
>> 251 /tmp> 
>> ===
>>  
>> Can you see what might be the culprit?
>>  
>> I understand this would happen if the value in the object itself does not 
>> change, whilst the value in the snapshot would; but how could change the 
>> attribute value of the snapshot without being written out to the database 
>> (which, if happened, would be logged as well)?
>>  
>> 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: updates to same value: why they happen?

2018-08-14 Thread ocs@ocs
Chuck,

> On 14 Aug 2018, at 7:37 PM, Chuck Hill  wrote:
> 
> Could there be some place in your code that is changing type between Integer 
> and Long?  EOF would see that as a value change, though the value logged 
> would appear the same.

thanks a lot, but actually I use BigDecimals for the attribute, and my accessor 
methods look like this:

===
  public java.math.BigDecimal originalAmount() {
return (java.math.BigDecimal) 
storedValueForKey(_DBAuction.ORIGINAL_AMOUNT_KEY);
  }
  public java.math.BigDecimal getOriginalAmount() { originalAmount() }
  public void setOriginalAmount(java.math.BigDecimal value) {
takeStoredValueForKey(value, _DBAuction.ORIGINAL_AMOUNT_KEY);
  }
===

given which I think it would not be the culprit, unless I am overlooking some 
trick. Weird.

Let me please check whether I recall properly how the sync betw. EC and 
snapshot works. Let's assume there's an enterprise object “eo” with an 
attributes “foo“ and “bar“. Let's assume x.foo=="a" at the moment. Now

1. user A starts a R/R loop and reads in eo to work with;
2. user B starts his own R/R loop, changes eo.foo to "b", savesChanges and ends 
its R/R loop;
3. user A — still in the same R/R loop of 1 — now

3a. makes some irrelevant changes without ever touching eo, and saves them. 
Since eo did never got into his updated object list, it's all right;

3b. he changes the eo.bar attribute (never changing eo.foo anyhow), and saves 
changes.

In this case, oops! eo.foo gets rewritten in the database to the old value of 
"a", for eo is amongst A's updated object list, and the live eo.a value differs 
from the snapshot — A's live value of eo.a would have been updated from 
snapshot at the end of the R/R loop, when EC unlocks; but that's in this case 
too late.

Right, is this the behaviour, or am I overlooking something here?

Thanks again a very big lot,
OC

>  
> From: Webobjects-dev 
>  on behalf of 
> "ocs@ocs" 
> Date: Tuesday, August 14, 2018 at 10:26 AM
> To: "webobjects-dev@lists.apple.com" 
> Subject: updates to same value: why they happen?
>  
> Gentlemen,
>  
> my code logs out all database changes in the 
> databaseContextWillPerformAdaptorOperations delegate method.
>  
> Lately from these logs I have found that one of my applications tends to 
> pretty often update an attribute to the same value it used to have before, 
> like this:
>  
> ===
> 249 /tmp> fgrep "UPDATE on 'DBAuction' ((uid = 1002533)" LOG
> 13:38:25.214|WorkerThread7 - 4: UPDATE on 'DBAuction' ((uid = 1002533)) 
> 1{originalAmount:11058}
> 09:02:58.136|WorkerThread2 - 1: UPDATE on 'DBAuction' ((uid = 1002533)) 
> 1{originalAmount:11058}
> 09:55:57.970|WorkerThread5 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
> 1{originalAmount:11058}
> 10:09:37.079|WorkerThread22 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
> 1{originalAmount:11058}
> 10:14:31.399|WorkerThread11 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
> 1{originalAmount:11058}
> 251 /tmp> 
> ===
>  
> Can you see what might be the culprit?
>  
> I understand this would happen if the value in the object itself does not 
> change, whilst the value in the snapshot would; but how could change the 
> attribute value of the snapshot without being written out to the database 
> (which, if happened, would be logged as well)?
>  
> 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: updates to same value: why they happen?

2018-08-14 Thread Chuck Hill
Could there be some place in your code that is changing type between Integer 
and Long?  EOF would see that as a value change, though the value logged would 
appear the same.

Chuck

From: Webobjects-dev 
 on behalf of 
"ocs@ocs" 
Date: Tuesday, August 14, 2018 at 10:26 AM
To: "webobjects-dev@lists.apple.com" 
Subject: updates to same value: why they happen?

Gentlemen,

my code logs out all database changes in the 
databaseContextWillPerformAdaptorOperations delegate method.

Lately from these logs I have found that one of my applications tends to pretty 
often update an attribute to the same value it used to have before, like this:

===
249 /tmp> fgrep "UPDATE on 'DBAuction' ((uid = 1002533)" LOG
13:38:25.214|WorkerThread7 - 4: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
09:02:58.136|WorkerThread2 - 1: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
09:55:57.970|WorkerThread5 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
10:09:37.079|WorkerThread22 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
10:14:31.399|WorkerThread11 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
251 /tmp>
===

Can you see what might be the culprit?

I understand this would happen if the value in the object itself does not 
change, whilst the value in the snapshot would; but how could change the 
attribute value of the snapshot without being written out to the database 
(which, if happened, would be logged as well)?

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


updates to same value: why they happen?

2018-08-14 Thread ocs@ocs
Gentlemen,

my code logs out all database changes in the 
databaseContextWillPerformAdaptorOperations delegate method.

Lately from these logs I have found that one of my applications tends to pretty 
often update an attribute to the same value it used to have before, like this:

===
249 /tmp> fgrep "UPDATE on 'DBAuction' ((uid = 1002533)" LOG
13:38:25.214|WorkerThread7 - 4: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
09:02:58.136|WorkerThread2 - 1: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
09:55:57.970|WorkerThread5 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
10:09:37.079|WorkerThread22 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
10:14:31.399|WorkerThread11 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) 
1{originalAmount:11058}
251 /tmp> 
===

Can you see what might be the culprit?

I understand this would happen if the value in the object itself does not 
change, whilst the value in the snapshot would; but how could change the 
attribute value of the snapshot without being written out to the database 
(which, if happened, would be logged as well)?

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