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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com >>> >>> 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/mschrag%40pobox.com > > 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]
