Re: Single stack optimistic lock exception?
Re: Single stack optimistic lock exception?
- Subject: Re: Single stack optimistic lock exception?
- From: Mike Schrag <email@hidden>
- Date: Fri, 24 Sep 2010 14:06:39 -0400
it's in the exception message, i believe ... I would also turn on adaptor debugging so you see the exact sql each instance thinks it's sending so you can match these up to what ends up in the db.
On Sep 24, 2010, at 1:50 PM, Ken Anderson wrote:
> It's a good question, and one I can probably check for when the exception happens. Will that be in the optimistic lock exception? Or do I have to hunt for it?
>
> On Sep 24, 2010, at 12:53 PM, Mike Schrag wrote:
>
>> just to make sure -- does the database have the new value and the snapshot has the old, or vice versa?
>>
>> ms
>>
>> On Sep 24, 2010, at 12:50 PM, Ken Anderson wrote:
>>
>>> It's Oracle RAC, so yes, a cluster.
>>>
>>> Yes, I'm REALLY sure it's single threaded.
>>>
>>> Yes, no way for someone else to change those rows, since we audit the tables with a trigger, and they weren't modified by anything else.
>>>
>>> The data type of the trans_id column is Number (12,0)
>>>
>>> Ken
>>>
>>> On Sep 24, 2010, at 12:37 PM, Miguel Arroz wrote:
>>>
>>>> Hi!
>>>>
>>>> What kind of DB are you using? Is it a single server, or a cluster?
>>>>
>>>> Are you REALLY sure it's single threaded (although that should not make a difference, because OL doesn't work anyway ;) )?
>>>>
>>>> Are you REALLY sure no other app, person, alien, cosmic ray, etc, is changing the conflicting rows at the same time?
>>>>
>>>> (Not my suggestion, but really good point ;) ) What is the data type of the column you use for locking?
>>>>
>>>> Regards,
>>>>
>>>> Miguel Arroz
>>>>
>>>> On 2010/09/24, at 16:56, Ken Anderson wrote:
>>>>
>>>>> All,
>>>>>
>>>>> I have an odd problem I'm wondering if anyone else has seen before.
>>>>>
>>>>> I have apps that do high throughput processing of data - many times a second. It is single threaded, and uses a single EOF stack. I'm sure it's single threaded because the requests are coming in via an inbound queue, not any kind of front end.
>>>>>
>>>>> Every once in a while under significantly high load, I get a few optimistic lock exceptions in a row, on rows that are only being touched by this app. We audit every update, and I can look into the audit tables and verify that nothing else has modified the record except this app.
>>>>>
>>>>> It's almost like the snapshot has not been recorded properly before the next request is processed, so EOF thinks something else updated the value.
>>>>>
>>>>> Our locking is implemented on a single column, trans_id, which is updated with every save. The audit table also saves the trans_id that's responsible for moving the record into audit, and all the values match in succession.
>>>>>
>>>>> Has anyone had anything like this happen? Running 5.4.3 on Linux. and no... no Wonder.
>>>>>
>>>>> Ken _______________________________________________
>>>>> 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
>>
>
_______________________________________________
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