> Please, I'm not that dumb, I know what an application is compared to a > simple web page.
Never suggested you were dumb, just pointing out the root of the issue. > All the same, we coldFusion developpers, are able to create complete > multi-user > true applications and work around THE HTTP "statelessness". The key phrase being "work around" - that's exactly what it is. Making a web app retain some idea of a cohesive session across HTTP requests is a work around of the inherent statelessness of the protocol. All a session is is knowing that two distinct requests within a given window of time are related Here's the rub - let's say someone goes to an edit form on a site, and the data row is then locked. Then they decide they want to do it later instead, so they browse off to some other site. How do you release the lock? They didn't commit a change and they didn't send any additional request to the server to close the session. Now, you could have a timeout on the lock, but it would have to be fairly short (minutes at most) to not be problematic. The more at risk the data is for a race condition, (i.e. the more likely a particular row is to have multiple editors) the more problematic a timeout mechanism is in this scenario. Now, let's say they didn't leave, but are simply taking a long time to do the edit. The lock times out underneath them and you are back to square one (no locking). In either case you could probably solve it using some sort of ping mechanism on the page to make sure they are still there, but now you have a bunch of extra network chatter going on while someone sits and looks at the form. Neither solution is great. > I is just too bad we have no tool to really control race conditions in > our databases, > and I just wonder how many among us really care about it. You are correct that there is no standard mechanism that handles this well. As others have pointed out, it's possible to handle in your code. I would certainly be all for someone coming up with a better toolset to manage this sort of thing. > If this kind of feature was implemented in ODBC or JDBC, and was > standard in SQL, there could be a tool in CF. > CF is able to keep connections open, manage time limits. > IF ODBC or JDBC was able to manage locks, there would be no problem. CF can manage database connections, but it's the lack of a persistent connection between the client and the server that's the problem, which is why the Oracle method doesn't work in a web environment - you simply don't know if the client is intending to complete the transaction and release the lock unless you "work around" the state issue. For all you know the have browsed off to EBay while your lock is still in force. > As I said, the CF server itself is able to manage sessions, the browser is > not important here. If there were proper tools in ODBC, CF could do it > easily. The browser is vitally important here. CF can hold database locks all day long, it's knowing what the client (the browser) is doing when there isn't an explicit request that is the issue. I don't disagree that there are situations where a race condition may need to be handled in a way that goes beyond what the environment natively supports - and with some creative coding, that can certainly be done. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252510 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
