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: Guy99 who wrote (8788)	1/15/1998 6:40:00 PM
From: Mark Finger	Read Replies (2) \| Respond to of 14631

>>The issue is really one of the granularity of the locking that you >>want to do and whether you want to lock physical or logical >>resources. If you're going to support RLL why not FLL (field level >>locking) and if FLL is good how about BLL (byte level locking), then >>there could be bLL (bit level locking). You can't get any more fine >>grained since a bit is the minimum size for information. The more >>fine grained your locking, the greater the overhead to manage to >>locks. This is an attempt to obscure the issue. In RDBMS, by definition, the row is the smallest set of data that is an independent set of data in a table. Data in one row cannot be dependent on any other row in the table. 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), or only one user needs to make a major change in a table (e.g., changing the basic definition of a field in a table by changing size or adding/deleting a field). In fact, page level locks are often faster to create than row level locks, and can be much more efficient if the level of contention is low (the Sybase assumption). Byte level locking is supported, but is not used in a RDBMS context (in fact, according to the rules, you should not know a byte offset of a record according to RDBMS rules). Your argument by creating a straw man and arguing to extremes shows an unreasonable bias. Granted that many application do not need RLL, but to argue as you do detracts from your other good postings.