Re: Encapsulate persistent variables
Bazlocking is not required on version 6 or higherin CF Admin you can set CF to auto-lock those scopes. Hope you're on 6 or higher ;-) Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229349 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
DOH!...and you obviouslky are on 6 or higher if you're using CFCs...hehe Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229350 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Encapsulate persistent variables
I'm on MX7, so it should be fine, but what about race conditions? Those can easily occur no? People don't lock their shopping carts in MX7? What about application scope vars, that's race-condition central.. Baz -Original Message- From: Bryan Stevenson [mailto:[EMAIL PROTECTED] Sent: Thursday, January 12, 2006 11:43 AM To: CF-Talk Subject: Re: Encapsulate persistent variables Bazlocking is not required on version 6 or higherin CF Admin you can set CF to auto-lock those scopes. Hope you're on 6 or higher ;-) Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229351 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
I'm on MX7, so it should be fine, but what about race conditions? Those can easily occur no? People don't lock their shopping carts in MX7? What about application scope vars, that's race-condition central.. Baz appliocation/session/server scopes are all handled automatically Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229355 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
doesn't locking all the scopes in the admin have an impact on performance? aren't you effectively single threading -every- reference to those scopes server-wide? no bottlenecking results from this? On 1/12/06, Bryan Stevenson [EMAIL PROTECTED] wrote: I'm on MX7, so it should be fine, but what about race conditions? Those can easily occur no? People don't lock their shopping carts in MX7? What about application scope vars, that's race-condition central.. Baz appliocation/session/server scopes are all handled automatically Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229358 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
According to MM, you still need to lock shared-scope variables to protect against race conditions. AFAIK, setting the locking in the CFadmin will affect performance. http://www.macromedia.com/cfusion/knowledgebase/index.cfm?event=viewid=KC.tn_18235extid=tn_18235dialogID=92334813iterationID=1sessionID=963070052628646c1818stateID=1+0+92344765mode=advanced ~Max On 1/12/06, Charlie Griefer [EMAIL PROTECTED] wrote: doesn't locking all the scopes in the admin have an impact on performance? aren't you effectively single threading -every- reference to those scopes server-wide? no bottlenecking results from this? On 1/12/06, Bryan Stevenson [EMAIL PROTECTED] wrote: I'm on MX7, so it should be fine, but what about race conditions? Those can easily occur no? People don't lock their shopping carts in MX7? What about application scope vars, that's race-condition central.. Baz appliocation/session/server scopes are all handled automatically Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: [EMAIL PROTECTED] web: www.electricedgesystems.com ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229361 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
Bryan Stevenson wrote: I'm on MX7, so it should be fine, but what about race conditions? Those can easily occur no? People don't lock their shopping carts in MX7? What about application scope vars, that's race-condition central.. appliocation/session/server scopes are all handled automatically They are not automatically protected against race conditions. Guess what happens when the following templates run concurrently: up.cfm: cfloop from=1 to=100 index=application.i step=1 do something /cfloop down.cfm: cfloop from=100 to=1 index=application.i step=-1 do something /cfloop Jochem ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229365 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Encapsulate persistent variables
Good example Jochem, I'm a bit surprised about how many people think that locking is unnecessary. The need to do it is definitely less noticeable nowadays because your server won't crash, but it's still essential. Imagine charging your customer too little or too much because s/he was accessing your session scoped shopping cart with 2 browsers... not fun. Locking is still required! (albeit in fewer cases) The solution of auto-locking in the CFAdmin is not optimal because, as Charlie Griefer mentioned, the performance impact could be catastrophic - especially if you were locking the application scope on every request! That would likely be your #1 bottleneck. It is in fact could practice to only use named locks. You should almost never lock an entire scope, except, perhaps, at app startup or some other rare case, but definitely not on every request. So this brings us back to the original question of how to manage all this. It would be nice to be able to encapsulate all locking somehow, and not have the developer worry about which variable was in what scope, and what's that lock name again? The developer would only reference the new custom scope called AppName (a CFC), that manages and contains all persistent vars. Oh, how that would be great... Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229380 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
I have an issue with using name locks. You would have to know the name of the lock you set up. I think that becomes very unmanigable unless you set up a dynamic name based on session. Named lockes on application scope are not needed. It's only going to be a one hit and that's it. The only place would be session. Someone pointed out that they don't lock the entire box, only the application then the scope. Bob ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229381 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Encapsulate persistent variables
Sir Robert Everland the III, You would have to know the name of the lock you set up. I agree. That's a downfall of using named locks, but another great reason to encapsulate all locking in 1 place! Named locks on application scope are not needed I disagree. If you were to update the application scope and not just read from it, you need to lock. Someone pointed out that they don't lock the entire box, only the application, then the scope. I agree. If you lock the session scope, I think it's only that specific session that's locked and not all sessions on the box - same with application scope, only a specific application is locked and not all applications on a box. Baz -Original Message- From: Robert Everland III [mailto:[EMAIL PROTECTED] Sent: Thursday, January 12, 2006 2:37 PM To: CF-Talk Subject: Re: Encapsulate persistent variables I have an issue with using name locks. I think that becomes very unmanigable unless you set up a dynamic name based on session. Named lockes on application scope are not needed. It's only going to be a one hit and that's it. The only place would be session. Someone pointed out that they don't lock the entire box, only the application then the scope. Bob ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229383 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Encapsulate persistent variables
Let's say you have a display TAG for Customer.CFC. And since we all know that TAGs should never access outside variables, we pass in Customer.CFC. All the TAG does is update some part of customer, and then displays its values. Now let's say instead of passing in a new instance of Customer.CFC you pass in session.CustomerObj. You've passed in a session scoped instance of Customer, but the TAG doesn't know it, nor should it. So where do you lock? Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229388 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Encapsulate persistent variables
My choice is to ensure the CFC takes care of all locking within itself. If a group of operations need to be locked, make a new method that calls all the other methods within the lock. Named locks work well for this kind of thing. One trick that can help with OO code is to create a unique lockname in the Init() method (based on a UUID) and save it as VARIABLES.myLockname (or similar). Then, all named locks for which you use that name are particular to that instance of the object. It doesn't matter where you instantiate it (SESSION, APPLICATION, whatever), the locks ensure that that object remains consistent and other instances of the same object can continue on their way without interference. If you really need to lock outside the object, you could create a getter method getLockName() (as long as that external lock applies only to that object and not data shared with other objects or other code). On 1/13/06, Baz [EMAIL PROTECTED] wrote: Let's say you have a display TAG for Customer.CFC. And since we all know that TAGs should never access outside variables, we pass in Customer.CFC. All the TAG does is update some part of customer, and then displays its values. Now let's say instead of passing in a new instance of Customer.CFC you pass in session.CustomerObj. You've passed in a session scoped instance of Customer, but the TAG doesn't know it, nor should it. So where do you lock? Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229412 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
