Interestingly enough... named locks were used throughout the old Spectra
code.. so whoever wrote the original thought otherwise. In fact we are
successfully using named locks in Spectra code to provide locking in the
server scope and under stress testing we see no server instability.
I'd argue that our internal testing appears to vindicate the use of named
locks in the server scope - though I'm happy to be proven wrong. Either
way, I for one would just like a straight answer as to how the hell locking
works in ColdFusion.
It's another one of these locking debates that really needs a technical
answer from the engineering team. Is there anyone in Allaire/Macromedia
that actually *knows* how this works?
A low level, technical answer would be welcomed - not some blanket statement
that all writes and reads must be locked as this is plainly wrong.
(I'm sure Dave will feel compelled to chime in as i know he has asked the
same question a 1000 times :)
I think for the time being our team is happy to continue using named locks
until real-world evidence shows us otherwise. Given the complexity of
caching and operations that Spectra performs in the server scope it seems
likely that server scope locking will add bottlenecks to the applications
performance.
-- Geoff
http://www.daemon.com.au/
> -----Original Message-----
> From: Raymond Camden [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 15, 2001 3:45 AM
> To: Spectra-Talk
> Subject: RE: Large mod - locking explanation?
>
>
> As Dave said, my understanding is that the _only_ 100% safe lock is the
> scope lock. Yes, this means that even if we are modifying Server.A we
> may block Server.B, but stability should win out over speed here.
>
> =======================================================================
> Raymond Camden, Principal Spectra Compliance Engineer for Macromedia
>
> Email : [EMAIL PROTECTED]
> Yahoo IM : morpheus
>
> "My ally is the Force, and a powerful ally it is." - Yoda
>
> > -----Original Message-----
> > From: Dave Watts [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 14, 2001 10:23 AM
> > To: Spectra-Talk
> > Subject: RE: Large mod - locking explanation?
> >
> >
> > > Not entirely sure why you've replaced all locking with SERVER
> > > rather than named locks. Surely this is likely to significantly
> > > increase the chance of contention throughout the application?
> > >
> > > I'd agree much of the locking throughout Spectra was inconsistent.
> > > Just wondering really what the thinking was behind this fairly
> > > significant set of modifications.
> >
> > It has been my understanding, based on what information
> > Allaire/MM provided about locking, that you'd have to lock
> > the Server scope itself if you're using any variables within
> > that scope - that is, if you simply created a name that you
> > used whenever accessing one nested structure within the
> > Server scope, the lock would be ineffective since other code
> > might access other nested structures within the Server scope,
> > and what really needed protection was the base structure itself.
> >
> > I certainly agree that this will increase contention, and
> > would be happy to be completely wrong about my understanding
> > of locking.
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
