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.

Technology Stocks : IFMX - Investment Discussion -- Ignore unavailable to you. Want to Upgrade?

To: Mark Finger who wrote (8793)	1/15/1998 7:16:00 PM
From: Guy99	Respond to of 14631

Sorry Mark, I think you misread my intent. To what end was I trying to obscure the point? Do you think I was arguing against RLL? Not so. I was trying to make the distinction between locking of logical and physical objects and I was also speaking about how SQL Server got to where it is. As to your argument about what kind of locking belongs in an RDBMS, I think I'd have to disagree. The relational model specifies what data can be accessed and how, it specifies NOTHING about the details of implementation. I can construct cases in which field level locking would provide much better performance that RLL. Byte level would be a little harder and I agree that, if it was exposed to the user, it would violate the Relational model. Bit level locking I included to be whimsical.

To: Mark Finger who wrote (8793)	1/15/1998 8:09:00 PM
From: Charles Hughes	Read Replies (1) \| Respond to of 14631

>>>However, data in one field (byte or bit) within a record is dependent on other fields (especially the index or key fields). This is one of Codd's basic laws for RDBMS. Therefore, RLL is the lowest level (in a RDBMS) at which locking should occur. Higher level locking (page, table, ...) can be used for performance reasons, especially if multiple rows are involved (e.g., an update involved in a join),<<< THIS IS CORRECT. I think people get confused by the fact that some databases allow you to put security on columns (fields) so that you can implement need-to-know and privacy policies. I have applied the misnomer of field-level-locking to this in a post some months ago. It is of course, not field locking but field-level-security. I would add that what you are often really interested in logically is a lock on a complete transaction including not just resulting updates but all input columns that go into making a calculation or whatever. The fact that these are likely to straddle each other or overlap in some way is precisely what makes sector locking such a nightmare. Often the workaround is basically to only process one request or transaction at a time in the database, except for select-only queries. There are two problems with that in Sybase: 1. It is extremely wasteful and makes a mockery of the benchmark results. 2. In at least earlier versions, even pure selects were allowed to block update and insert locking entries, and there was no statement by which you could code around this, and no reasonable default, such as the default, sensible locking that Informix has, which will not block a select with an update or vice - versa, unless you want to. In my current situation, I funnel all web server requests through a markup product that uses a single login, and I keep all requests very simple. This kills all parallelism but allows me to use SQL Server (which was cheap) in a situation with very very low volume, and get reasonable response time. This will not scale. Chaz