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/archive%40mail-archive.com This email sent to [email protected]
