Re: Best database for web backend on Linux?
--------------03D05580B92998E958D76A5D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jurij, Thanks for the explanation. Let's see if I can put this in perspective. We have two users, both trying to access the same table and the same rows. User #1 gets a cursor on a select and marks all the rows in the cursor as locked for update. This means that Oracles client tools (or server) needs to insert this information into the header of the database block (this means at least one phisical I/O call "fwrite()" per locked row). Now user two comes along and wishes to select one of these rows for update as well (at the same time). This means that user #2 will need to read this table at the head of the database (it is probably not indexed all that well so will ammount to a table scan) prior to recieving a lock. Having failed on the first try, the user could then be notified or we could poll the header record until the lock clears (yuck). While this doesn't represent the publish method I theorized, it does represent an implied publish none the less, because in order to operate on any database object where locking is in play, you first have to see if any of the members of your result set are locked for update. This means going to the central "bullitin board" where such notices are posted. Ideally, if this were a perfect product, that information would be storred in a regular table that was cached in its own memory pool, but your information suggests it is storred in some kind of proprietary (non-SQL capable) table not in cache. Out of curiosity, I don't suppose you would know why information that is not critical to data integrety is kept on disk? After all, if the connection times out, or the server crashes, what use is lock information on an update that is never going to happen. Now, my information might be a bit old, but last I checked, Oracle does both page and row based table management. While My information doesn't include weather or not both are done at the same time, I do know that other vendors do this. That being the case, If Oracle does, that means keeping track of both pages and how they are being filled and rows and weather they are being locked. Each one of these represents an I/O call, hopefully to cache, tho as you suggest this would probably go to disk. Any information you might be able to share on this one would be of great help too. -- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew --------------03D05580B92998E958D76A5D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Jurij, <P>Thanks for the explanation. Let's see if I can put this in perspective. We have two users, both trying to access the same table and the same rows. User #1 gets a cursor on a select and marks all the rows in the cursor as locked for update. This means that Oracles client tools (or server) needs to insert this information into the header of the database block (this means at least one phisical I/O call "fwrite()" per locked row). Now user two comes along and wishes to select one of these rows for update as well (at the same time). This means that user #2 will need to read this table at the head of the database (it is probably not indexed all that well so will ammount to a table scan) prior to recieving a lock. Having failed on the first try, the user could then be notified or we could poll the header record until the lock clears (yuck). While this doesn't represent the publish method I theorized, it does represent an implied publish none the less, because in order to operate on any database object where locking is in play, you first have to see if any of the members of your result set are locked for update. This means going to the central "bullitin board" where such notices are posted. Ideally, if this were a perfect product, that information would be storred in a regular table that was cached in its own memory pool, but your information suggests it is storred in some kind of proprietary (non-SQL capable) table not in cache. Out of curiosity, I don't suppose you would know why information that is not critical to data integrety is kept on disk? After all, if the connection times out, or the server crashes, what use is lock information on an update that is never going to happen. <P>Now, my information might be a bit old, but last I checked, Oracle does both page and row based table management. While My information doesn't include weather or not both are done at the same time, I do know that other vendors do this. That being the case, If Oracle does, that means keeping track of both pages and how they are being filled and rows and weather they are being locked. Each one of these represents an I/O call, hopefully to cache, tho as you suggest this would probably go to disk. Any information you might be able to share on this one would be of great help too. <PRE>-- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: <A HREF="http://home.msen.com/~carew">http://home.msen.com/~carew</A></PRE>; </HTML> --------------03D05580B92998E958D76A5D--