Indeed. Good distinction to understand. In my case, the latter is
almost always what I'm looking for. Obviously this concept could be
extended to support "on an individual attribute basis" but that's
probably not worth the bother.
Anjo Krank wrote:
Note that these are two different things. The one is "i have these attributes which I consider
'important'", the other is "any change is equally important".
Cheers, Anjo
Am 09.12.2009 um 18:14 schrieb Kieran Kelleher:
Hi Jon,
Actually that is a good tip, record version control integers attributes definitely seem
like a solid approach for optimistic locking in sensitive situations (combined with
OptimisticLockAction dbc.lock of course as discussed last week with Dr. iguel
"Optimistic Locking" Arroz. ;-) ) I think I will go this serialNumber route,
just because I feel more comfortable/trusting of it for the particular situation I have.
Regards and thank, Kieran
On Dec 9, 2009, at 12:01 PM, Jon Nolan wrote:
Kieran Kelleher wrote:
Am I dreaming in thinking that I saw a discussion at some time in the past that
there is some flaw with using BigDecimals as reliable* optimistic locking
attributes? ..... or was that just NSTimestamps and float/double type values?
.....
Kieran,
I seem to remember some trouble with this in the past involving precision but,
like you, I don't remember if it extended to BigDecimal. Doesn't seem like it
should given what that class is all about.
I've given up on struggling with various locking attribute types and have gone
with locking on primary key and an int/long called serialNumber. Then I have
something like this in the eo class.
public void willInsert() {
super.willInsert();
setSerialNumber(0);
}
public void willUpdate() {
super.willUpdate();
setSerialNumber(serialNumber().intValue() + 1);
}
I have zero failures with this approach and perhaps just as importantly zero
headaches. The only (slight) negative is a bit of DB bloat.
Jon
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
