LiveDocs Comments - coldfusion - 6 - Developing_ColdFusion_MX_Applications_with_CFML - sharedVars8.htm

coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/sharedVars8.htm

Sabaidee — 2006-09-10T23:07:43

halL makes perfect sence. No screen name's example uses an exclusive application-scope lock inside a read-only application-scope lock, which can create a dead-lock (quote: 'You can also cause deadlocks if you nest locks of different types. An example of this is nesting an exclusive lock inside a read-only lock of the same scope or same name.')
To be safe rather than sorry use the example in the main doc.

coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/sharedVars8.htm

halL — 2004-09-17T10:50:54

Please note: I've marked this as a Macromedia comment, but I'm a technical writer, not a lock expert, so this might not be the final word.

First, timeouts are required, as indicated in the comments. We will fix this error in the documentation for the next release.

Second, no screen name corrected the initial extremely long timeouts down to 30 seconds in a second posting. That might still be higher than necessary, but it isn't totally unreasonable.

Third, I believe that the reasoning behind the suggested technique is that this code maximizes efficiency, as follows.

First, note that there are no nested locks. You cannot nest a lock of one type inside a lock of the same type: the scope is already locked, so the inner lock would just time out.

The read-only lock contains code that every page in the application must execute. It can be entered simultaneously by multiple pages and has only one line inside it. However, if the application scope variables are not set yet, the read-only lock must be released before the exclusive lock can be taken and the variables can be set.

Because multiple pages might be in the read-only lock at one time, there is a possibility that multiple pages could end up with a false local app_is_initialized variable following the read-only lock code. All these pages would end up going through the exclusive lock code (unless they timed out). The re-check of the local variable tests whether one of those other pages has beaten the current page to setting the variables, and avoids the cost of multiple sets at the expense of one read.

Does this make sense?

coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/sharedVars8.htm

parrot person — 2004-09-16T15:47:18

WHOAH. I am *really* not understanding the point of those lengthy timeouts in No screen name's example! I have a suspicion that noname is confusing the timeout of the lock with the timeout of application variables themselves.

Anyone from Macromedia care to comment?

Also, the second check for IsDefined("Application.initialized") seemed redundant to me too. Again, anyone from Macromedia care to explain why we need that second one?

coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/sharedVars8.htm

2004-08-17T15:05:11

My bad on posting above (got side track):
Timeout should be like 30 for both cflocks, because it is how long will it wait before responding to timeOutThrown if specified in lock...

coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/sharedVars8.htm

2004-08-17T14:54:55

Example above not complete and can be more efficient. First, it does not include cflock timeouts. I found the inside (2nd) cfif initialized creates inconsistancies in session variables (also duplicate of previous cfif for how got in). I saw no reason for the 2nd setting of app_is_initialized inside the inner cflock, for it was set to that anyways to pass cfif to get in. NOTE: My example is based on 2 days for times. Reasoning is I do not change application variables regularily (centeralization of common variables, and not trackers for in most cases there are more efficient ways). Given that customize them to your uses...

...