Re: Big Decimal as optimistic lock attribute?
Re: Big Decimal as optimistic lock attribute?
- Subject: Re: Big Decimal as optimistic lock attribute?
- From: Jon Nolan <email@hidden>
- Date: Wed, 09 Dec 2009 11:26:39 -0700
- Organization: Loch Garman
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden