-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Farrar Sent: Thursday, 5 August 2004 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Data Locking is it too hard?
1. Other than locking the DB... why are you trying to lock it? (i.e. ... the web is stateless, so the CF Lock would only function to lock a transaction occuring during this request.) Scott:> The reason I have to engage a lock procedure is to counter-act the fact that the web is stateless. The easy part kicks in when you are doing the initial request, in that you can lock & so forth a db. But the moment the request is finished (ie form is displayed ready for editing) the data is considered "expired" and the reason you have to consider this, is simply that it could have been changed by the time you go to initiate the save request. Thus we are in the situation which I ask, in that how do you lock a row in a stateless environment. 2. If you are trying to run a sql command that takes longer than a standard request... why aren't you doing that from inside your sql server? (and with that... what SQL server are you using? ... is this a internal server... or rented shared server online?) Scott:> Informix is our current database, but its not that bad all said & done. The key is if we were to shift the logic back into the database, and on the pull request, you request a lock be put on that row while you edit. The trouble kicks in, when the time comes to do another request, how do you inform the DB that you are the originator of a given lock? 3. If this is a CMS type check in check out lock, then you could do a combination of (with msSQL... not in access) locking the transaction to make sure only one person can do this at a time, having it create a GUID key to show it is locked, and to check it back it, and when the user gets done... or when your application says he had it checked out to long if you want that... log it checked back in. Heh... that is a quick (not carefully worded) overview of what it sounds like you need. Scott:> Yup, We had considered just modifying the existing table schemas to cope with new checkin/checkout timestamp procedures. That concept would work fine, but we thought rather then touching the existing DB, simply clone the DB (without data), and adjust CFMX/StoredProc queries to check for existance of records within the shadow db, if it does exist consider that a virutal lock. Granted this is extra over-head but this will open up the ability for users to sort of create a data buffer before they commit, in that they can save portions of data from within a screen as they go, so in the event Internet Explorer / Machine crashes, it can keep portions of their work in a separate area meanwhile the full traffic of the application continue to see the LIVE data? But yeah, the key to this whole procedure at the end of the day is to emulate a lock in a virutal fashion, and only do an actual real deal lock when you are modifying live data (ie final actual CFMX request). In doing this, it also allows us to put the transaction around the actual query(s) themselves instead of in many ways the presenter. Thankyou John for your reply. Regards Scott Barnes Senior Web Developer Alpha Business Systems [EMAIL PROTECTED] 1/31 Thompson St Bowen Hills QLD 4006 Ph +61 07 3216 0999 http://www.alphabus.com.au ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
