How about solving it with AJAX or using Flash forms that use sockets to check whatever the current user is still editing? You could even popup a message like "You are taking a long time to edit" or "Someone else wants to edit this data - please either release it or finish your work ASAP".
TK > 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:252519 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
