*) Rule of thumb: use SCOPE attribue with value of session for the whole app(consistently) is safer than using NAME attribute in general or when in doubt.
*) Still no crystall clear/no definite answer as to "When to use SCOPE and When to use NAME", a quote from one of MM's article on the subject, "Using the name attribute is useful when you want a high level of granularity in your locking.", it needs collaboration and case scenario.
And when it's determined that using NAME attribute is preferable to using SCOPE, then when to use static/same NAME for a lock content and when to use dynamic lock NAME becomes a question, quote from MM, "Note that you should never ever use different names for locks on code that accesses the same data", implys that in most cases, use static/same lock name, but part of of quote, "accesses the same data" seem confusing, because normally, data within a lock may vary from users.
It would be a great value addition if MM clarify that.
> 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?
> 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?
>
> 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)?
>
> (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?
>
> Thank you.
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
