updates to same value: why they happen?

[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

[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 <webobjects-dev-bounces+chill=***@lists.apple.com> on behalf of "***@ocs" <***@ocs.cz>
Date: Tuesday, August 14, 2018 at 10:26 AM
To: "webobjects-***@lists.apple.com" <webobjects-***@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

[ocs@ocs]

Chuck,

Post by 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.

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

Post by Chuck Hill
Date: Tuesday, August 14, 2018 at 10:26 AM
Subject: updates to same value: why they happen?
Gentlemen,
my code logs out all database changes in the databaseContextWillPerformAdaptorOperations delegate method.
===
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

[ocs@ocs]

Ha! Seems I have found the culprit. Thanks a lot for the advice

Post by ***@ocs

Post by Chuck Hill
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

Post by ***@ocs
Chuck,

Post by 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.

===
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

Post by Chuck Hill
Date: Tuesday, August 14, 2018 at 10:26 AM
Subject: updates to same value: why they happen?
Gentlemen,
my code logs out all database changes in the databaseContextWillPerformAdaptorOperations delegate method.
===
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