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 (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com >>>> >>>> This email sent to ar...@guiamac.com >>> >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to msch...@pobox.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
