Re: Big Decimal as optimistic lock attribute?
Re: Big Decimal as optimistic lock attribute?
- Subject: Re: Big Decimal as optimistic lock attribute?
- From: Kieran Kelleher <email@hidden>
- Date: Wed, 9 Dec 2009 13:46:55 -0500
I agree.
On Dec 9, 2009, at 1:20 PM, 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:
@krank.net
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