Consider the scenario of another application accessing the same database. An 
application scoped lock won't be honoured by a foreign application. The ONLY sure fire 
way to ensure atomic transactions is to have the db engine take care of it. CFLOCK & 
CFTRANSACTION = apples & oranges, chalk & cheese, etc.


> Hmmm.... I thought that in the case of Access (the db being discussed,
> IIRC) that *both* would work, so long as the cflock was in the
> application scope.
> AFAIK, Access only supports table-level locking, not record-level
> locking. I'd assumed that when certain database operations 
> are performed
> (all?), Access locks the table being referenced anyway. So if you've
> wrapped your code in a cftransaction, ColdFusion says "OK 
> Access, group
> these together in a transaction". As the table was locked 
> from the first
> insert, the second template won't have a chance of running until the
> first cftransaction has run it's course.
> 
> Alternatively, if you had an application scope cflock, then I'd have
> thought that would work too, but the logic would be handled by
> ColdFusion, not the table-locking on the db -- CF simply wouldn't pass
> off the second insert until the first select was completed. Obviously,
> if the cflock wasn't at the application level, CF would pass them both
> on regardless and you're pooped.
> 
> Correctamundo?
> 
> 
> -- 
> Aidan Whitehall <mailto:[EMAIL PROTECTED]>
> Macromedia ColdFusion Developer
> Fairbanks Environmental Ltd  +44 (0)1695 51775
> Queen's Awards Winner 2003 <http://www.fairbanks.co.uk/go/awards>
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
> 
> -- 
> ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/
> 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> For human help, e-mail: [EMAIL PROTECTED]
> 
> 

--
** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]

Reply via email to