> Exactly. I agree. My statement was simplistic. No, sir; your statement was patently wrong. I think you still have an idea that there is an inherent relationship between transactions and (regardless of transport mechanism) the timing of requests that arrive at the database. This is simply not true, and you are still confusing the two issues.
> If all actions on a DB were made completely in > serial there would be little need for the kind of transactionalized > processing we're talking about. Jim, this is a ridiculous statement that is misleading people on this list, and it furthers my claim that you are not grasping the real meaning of what transactions really do. > You still have the complexity (internally) of memory vrs disk state (another > topic best left out, I think, when dealing with beginners), Without a solid understanding of this most critical topic, beginners will never advance because they cannot truly grasp exactly what transactional isolation does. > All the usage complexity if transactions come from multi-process issues, not > encapsulation. It comes from both, because they are inextricably linked. Encapsulation of set-based statements into an atomic action, and the isolation of that action from other actions that attempt to modify or access data (or even the structures related to that data), are two peas of the transactional pod. > The only reason that threading hasn't any impact on this is BECAUSE of > transactionalized processing (which, I think, enforces my point). "Transactionalized processing?" What exactly do you mean by this? > If there > was no transactional capability then all statements from all users would > come in pell-mell and cause havoc. Jim, you need to look carefully at the internals of modern database systems and all their related subsystems before making a statement like this. It's just plain wrong. I assume you're referring to implicit rather than explicit transactions here, but even these are set-based statements, not individual row modifications as in the ISAM world. This has more to do with the way SQL works with sets of data rather individual rows than it does with transactions. > Transactions (whether explicitly or implicitly set) allow the DB to manage > multiple processes (I used the term "threads") effectively. Transactions do not allow the DB to manage multiple processes effectively, Jim. > I heartily admit that on the literal interpretation of my statement I was > wrong but I still feel strongly that the spirit of the statement: that DB > transactions are VERY IMPORTANT to managing shared resources is true. No, I have to say that your concept of transactions is quite simply incorrect, Jim. I'm only saying this because people on this list hear things like this and take it as fact, then begin basing everything they do from that point forward on wrong information, and it's detrimental. I don't comment on very much on this list because I just don't have the time with everything else we're doing (including some incredible free stuff we're developing for the ColdFusion community), but when I get a chance and see something that needs a serious correction, I try to set things straight. Please don't take my intentions wrong, Jim. We spend a full four hours on this topic in our database class because of its complexities -- even at it simplest level, if it is to be truly understood -- and its importance to excellent development. There are more misconceptions on this topic than just about any other that I've seen. If I've offended, then I apologize, because it was never my intention to do so. Respectfully, Adam Phillip Churvis Member of Team Macromedia Advanced Intensive ColdFusion MX Training Advanced Development with ColdFusion MX and SQL Server 2000: August 11 - 15, 2003 http://www.ColdFusionTraining.com Download CommerceBlocks V2.1 and LoRCAT from http://www.ProductivityEnhancement.com The ColdFusion MX Bible is in bookstores now! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
