> Jim, > > I'm sorry to say that your entire concept of threading and transactions is > incorrect. I don't mean to hassle you over this, but it's steering people > in the wrong direction. > > Transactions were not created to either manage or account for threading > issues; the transaction occurs in an entirely different layer of the > architecture altogether. Transactions exist for one reason only, and that > is to ensure that all such statements that compose a transaction are > considered as a single atomic action.
Exactly. I agree. My statement was simplistic. BUT - the fundamental reasons that things NEED to be grouped this way, treated as atomic units, is that multiple actions can occur from multiple users at the same time. 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. If all actions taken were in serial then the concept of "transactions" wouldn't exist beyond a simple "undo". You would, instead of locking the resource(s), performing the statements and then committing (or rolling back) the transaction simply be marking the start point of the "statement stream". When done you would commit that to disk or throw it away. All the usage complexity if transactions come from multi-process issues, not encapsulation. You still have the complexity (internally) of memory vrs disk state (another topic best left out, I think, when dealing with beginners), but that's nothing compared to effectively managing race conditions and shared resource access. If we lived in serial world you may still have a "Transaction" statement, but it would be quite a different beasty. > escalation, which in turn impacts transactional isolation all over again. > None of this has much to do with threading; if you completely changed how > the requests arrived at the database engine, nothing would change with > respect to transaction execution. The only reason that threading hasn't any impact on this is BECAUSE of transactionalized processing (which, I think, enforces my point). If there was no transactional capability then all statements from all users would come in pell-mell and cause havoc. Transactions (whether explicitly or implicitly set) allow the DB to manage multiple processes (I used the term "threads") effectively. I was using the term "thread" in a very simplistic, non-technical way both from weariness (it was 5 am...) and because I was attempting to simplify the explanation for the original poster. 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. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
