Re: Big Decimal as optimistic lock attribute?
Re: Big Decimal as optimistic lock attribute?
- Subject: Re: Big Decimal as optimistic lock attribute?
- From: Anjo Krank <email@hidden>
- Date: Wed, 9 Dec 2009 19:20:31 +0100
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