Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

SI - Site Forums : Silicon Investor - Legacy Interface Discussion (2004-2011) -- Ignore unavailable to you. Want to Upgrade?

To: SI Dave who wrote (2241)	10/13/2004 9:04:05 AM
From: Glenn Petersen	Respond to of 6035

>>Please say it was number 2.<< Unfortunately no. As for the message referenced in your prior post, I can't say one way or the other that I remember it being in my Inbox.

To: SI Dave who wrote (2241)	10/13/2004 12:32:37 PM
From: SI Bob	Respond to of 6035

That's going to really, really suck if it's a timing issue. Message insertion is such a rare event in the big picture of the kind of work the db box does and can do that it should be safe to work from an understanding that the db box will never be asked to do more than one at a time. Even an 18ms gap should be enormous. But it's also possible that even an ISP outage lasting a relatively short amount of time can result in a collision-causing mini-flood whenever the lights turn back on. I'd better do a little reading and see if I need to wrap the message insertion routines in transactions and use explicit locks. If this is the solution for this problem, it'll also be the solution to the problem of the occasional intra-thread message number duplication.

To: SI Dave who wrote (2241)	10/13/2004 12:55:57 PM
From: SI Bob	Read Replies (1) \| Respond to of 6035

I definitely can't make these kinds of changes during market hours, so this evening I'll look more closely at and possibly make some changes to the way the message insertion routines work. I'm looking at the proc now and can see how a mini-flood could cause some inserts to fail on primary key violations, and I really don't know if the other lines in the proc would run if the pk-violating line failed. I strongly suspect that if a line fails, the rest don't get hit and if a primary key violation is going to happen in this proc, it's going to happen on the first line that actually does anything but reading.