Don
>I am a bit rusty on this topic, but this is all what I remember. If anyone
>finds a mistake please correct me.
> -----Original Message-----
> From: Chunshen (Don) Li [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 29, 2004 1:26 PM
> To: CF-Talk
> Subject: the ever popular cflock best practice revisited
>
>
> Hi,
>
> I've inherited an app that does not lock session variables. The app runs
>under CF5.0.
>
> Have read cflock best practice for CF5.0. Here are a few questions:
> (A) CFLOCK
> 1) heard that cf5 server and cfmx server handles cflock differently, so,
>would cflock best pratice for cf5 applicable to cfmx if one day the app
>upgraded to cfmx?
> [Tom Kitta]
> In CF5 locking was needed because all persistent scope variables
>(session/application and server) could become corrupted if accessed at the
>same time. Could even crash the server (or so theory goes). In CFMX thanks
>in part to Java, this is no longer the case. However, you still need cflock
>tag for the race conditions (rare occasions, but still does happen).
In sum, it seems applying cflock is part of best practice for both preCFMX and CFMX.
> 2) what about this notion of the NAME attribute, that is, a different lock
>name would differentiate data/value inside a lock (be it read and write when
>applicable), the analog of gym's lock room. No? with a SAME lock NAME, cf
>server (5.0/prior and cfmx) would treat each request as students line up to
>try that SAME lock with each one having a key/request in his/her hand?
>
> [Tom Kitta]
> The name is used when you don't actually lock the persistent scope
>variables. The lock doesn't care what's in it, it just single threads all
>requests.
Thanks for the clarfication, good to know, in other words, when NAME is used regardless of the value of NAME itself CF server applys "single thread" for all requests.
> 3) given the fact that SCOPE and NAME attributes are mutually exclusive,
> use one of them would suffice, so, the question is when to use SCOPE and
>when to use NAME (data integriy number one task, less memory usage second
>for either preCFMX or CFMX)?
>
> [Tom Kitta]
> Name is less used since it is not for session/application/server. You can
>use it to say single thread file access for example.
I took your comment as SCOPE is preferable to NAME for performance sake, yes?
>
> (B) Single Threaded Sessions (CF Admin)
> Could we construe that Single Threaded Sessions mechanism is a way that MM
>designed to overcome the lousy coding of not locking session variables? By
>that, I mean, so, instead of going through tons of code modification, just
>apply the "Single Threaded Sessions" to let CF server to handle the locks
>for data integrity. How well does "Single Threaded Sessions" does this job?
>
> [Tom Kitta]
> As far as I know this is last resort as it will slow down the server
>considerably. I would not use it for production, maybe for debugging on
>development server.
Agree as last resort. I intend to re-code all the session variable written by prior developer for the app with SCOPE attribute of session, then run two testing {sessions} with concurrent users with "Single Threaded Sessions" off and on.
I hope this course of action is the best option to circumvent the inherited problem.
Again, thank you very much.
>
> Thank you.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
