Re: CFCs, TAGs, Locking
maybe you could make a copy of your object in the request scope onRequestStart and then work with request.OrderObj On 1/18/06, Baz [EMAIL PROTECTED] wrote: Let's say you have a display TAG called DisplayOrder.cfm that accepts as an argument OrderObj.cfc. Basically the TAG displays the contents of the CFC. Let us also say that in 1 particular case you are passing an OrderObj that is stored in the application scope to the TAG. Where do you employ locking to avoid race conditions? It can't be within the TAG because sometimes locking is not necessary. So do you lock the entire call to the tag like so: cflock Order:Display OrderObj=#application.OrderObj# /cflock Does that even lock everything that happens within the tag and stop race conditions? Isn't it extremely inefficient to lock a potentially huge chunk of code when only a couple of lines really need to be locked? How do people generally handle this? Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229875 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: CFCs, TAGs, Locking
Hi Michael, There are a couple of issues with copying my persistent variable to the request scope. First of all, in this particular case, the main reason for persisting the object is purely performance. Its an object that gets extremely often and persisting it saves a lot of milliseconds. So copying it on every request would defeat the whole purpose of persisting it. Secondly, it's not so easy to clone CFCs. You would need to write a custom function that again would be killer to performance. Thanks for the suggestion anyhow, Baz -Original Message- From: Michael Traher [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:42 AM To: CF-Talk Subject: Re: CFCs, TAGs, Locking maybe you could make a copy of your object in the request scope onRequestStart and then work with request.OrderObj On 1/18/06, Baz [EMAIL PROTECTED] wrote: Let's say you have a display TAG called DisplayOrder.cfm that accepts as an argument OrderObj.cfc. Basically the TAG displays the contents of the CFC. Let us also say that in 1 particular case you are passing an OrderObj that is stored in the application scope to the TAG. Where do you employ locking to avoid race conditions? It can't be within the TAG because sometimes locking is not necessary. So do you lock the entire call to the tag like so: cflock Order:Display OrderObj=#application.OrderObj# /cflock Does that even lock everything that happens within the tag and stop race conditions? Isn't it extremely inefficient to lock a potentially huge chunk of code when only a couple of lines really need to be locked? How do people generally handle this? Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229878 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: CFCs, TAGs, Locking
If you are just displaying information, I would say that in like 99.9% of the time, even with race conditions, you wouldn't have to lock. Think about what the worst case scenario is here? Is it possible that you could display corrupt data, and if so, is it mission criticle? ... Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:33 AM To: CF-Talk Subject: CFCs, TAGs, Locking Let's say you have a display TAG called DisplayOrder.cfm that accepts as an argument OrderObj.cfc. Basically the TAG displays the contents of the CFC. Let us also say that in 1 particular case you are passing an OrderObj that is stored in the application scope to the TAG. Where do you employ locking to avoid race conditions? It can't be within the TAG because sometimes locking is not necessary. So do you lock the entire call to the tag like so: cflock Order:Display OrderObj=#application.OrderObj# /cflock Does that even lock everything that happens within the tag and stop race conditions? Isn't it extremely inefficient to lock a potentially huge chunk of code when only a couple of lines really need to be locked? How do people generally handle this? Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229879 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: CFCs, TAGs, Locking
Very good point Ben, I was waiting for such a comment. But what if the TAG *does* update itself? Perhaps it allows you to choose an ID and gets some info from the DB based on it? Plus there are no guarantees as to what's happening inside the CFC. Perhaps to return data it must update an internal variable first. You don't really know and you shouldn't have to, that's one of the beauties of CFCs. There must be a more secure, robust way of making TAGs scope agnostic. TAGs shouldn't have to know how the CFCs they are passed work or where they are stored. One bad solution would be to have a second trimmed down version of the CFC, that you use specifically to pass to TAGs. This CFC would contain only the methods that are safe no matter what scope the CFC is in. The problems with this are infinite though. Cheers, Baz -Original Message- From: Ben Nadel [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:51 AM To: CF-Talk Subject: RE: CFCs, TAGs, Locking If you are just displaying information, I would say that in like 99.9% of the time, even with race conditions, you wouldn't have to lock. Think about what the worst case scenario is here? Is it possible that you could display corrupt data, and if so, is it mission criticle? Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 11:33 AM To: CF-Talk Subject: CFCs, TAGs, Locking Let's say you have a display TAG called DisplayOrder.cfm that accepts as an argument OrderObj.cfc. Basically the TAG displays the contents of the CFC. Let us also say that in 1 particular case you are passing an OrderObj that is stored in the application scope to the TAG. Where do you employ locking to avoid race conditions? It can't be within the TAG because sometimes locking is not necessary. So do you lock the entire call to the tag like so: cflock Order:Display OrderObj=#application.OrderObj# /cflock Does that even lock everything that happens within the tag and stop race conditions? Isn't it extremely inefficient to lock a potentially huge chunk of code when only a couple of lines really need to be locked? How do people generally handle this? Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229899 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: CFCs, TAGs, Locking
What about having an attirubte of the tag (LOCK) that defaults to false? When there are race conditions, are you going to know when they happen? Like, if the timing is contextual, you could put lock=true in the appropriate call to the tag? Never done that, but an idea ... Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 1:10 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking Very good point Ben, I was waiting for such a comment. But what if the TAG *does* update itself? Perhaps it allows you to choose an ID and gets some info from the DB based on it? Plus there are no guarantees as to what's happening inside the CFC. Perhaps to return data it must update an internal variable first. You don't really know and you shouldn't have to, that's one of the beauties of CFCs. There must be a more secure, robust way of making TAGs scope agnostic. TAGs shouldn't have to know how the CFCs they are passed work or where they are stored. One bad solution would be to have a second trimmed down version of the CFC, that you use specifically to pass to TAGs. This CFC would contain only the methods that are safe no matter what scope the CFC is in. The problems with this are infinite though. Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229912 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: CFCs, TAGs, Locking
The first suggestion! Thanks. It seems like it would work but coding locking stuff in EVERY tag just in case it *might* need it seems like a lot of overhead. Maybe the only solution is to never pass in objects and only pass in local structs to TAGs. That way you can be sure no weird modifications occur. Maybe its bad practice to have a TAG do anything besides display. Baz -Original Message- From: Ben Nadel [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 2:24 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking What about having an attirubte of the tag (LOCK) that defaults to false? When there are race conditions, are you going to know when they happen? Like, if the timing is contextual, you could put lock=true in the appropriate call to the tag? Never done that, but an idea Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 1:10 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking Very good point Ben, I was waiting for such a comment. But what if the TAG *does* update itself? Perhaps it allows you to choose an ID and gets some info from the DB based on it? Plus there are no guarantees as to what's happening inside the CFC. Perhaps to return data it must update an internal variable first. You don't really know and you shouldn't have to, that's one of the beauties of CFCs. There must be a more secure, robust way of making TAGs scope agnostic. TAGs shouldn't have to know how the CFCs they are passed work or where they are stored. One bad solution would be to have a second trimmed down version of the CFC, that you use specifically to pass to TAGs. This CFC would contain only the methods that are safe no matter what scope the CFC is in. The problems with this are infinite though. Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229914 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: CFCs, TAGs, Locking
Baz wrote: The first suggestion! Please don't think the lack of response is because the subject is not interesting. It is because it is hard :) Anybody up for building a CFUnit test that passes when run single-threaded, but fails when running simultaneously? Jochem ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229929 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: CFCs, TAGs, Locking
Baz, In general, I use my tags only to do display stuff. I think that's the way to go IMO. ... Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 2:55 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking The first suggestion! Thanks. It seems like it would work but coding locking stuff in EVERY tag just in case it *might* need it seems like a lot of overhead. Maybe the only solution is to never pass in objects and only pass in local structs to TAGs. That way you can be sure no weird modifications occur. Maybe its bad practice to have a TAG do anything besides display. Baz -Original Message- From: Ben Nadel [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 2:24 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking What about having an attirubte of the tag (LOCK) that defaults to false? When there are race conditions, are you going to know when they happen? Like, if the timing is contextual, you could put lock=true in the appropriate call to the tag? Never done that, but an idea . Ben Nadel Web Developer Nylon Technology 350 7th Ave. Suite 1005 New York, NY 10001 212.691.1134 x 14 212.691.3477 fax www.nylontechnology.com Sanders: Lightspeed too slow? Helmet: Yes we'll have to go right to ludacris speed. -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 1:10 PM To: CF-Talk Subject: RE: CFCs, TAGs, Locking Very good point Ben, I was waiting for such a comment. But what if the TAG *does* update itself? Perhaps it allows you to choose an ID and gets some info from the DB based on it? Plus there are no guarantees as to what's happening inside the CFC. Perhaps to return data it must update an internal variable first. You don't really know and you shouldn't have to, that's one of the beauties of CFCs. There must be a more secure, robust way of making TAGs scope agnostic. TAGs shouldn't have to know how the CFCs they are passed work or where they are stored. One bad solution would be to have a second trimmed down version of the CFC, that you use specifically to pass to TAGs. This CFC would contain only the methods that are safe no matter what scope the CFC is in. The problems with this are infinite though. Cheers, Baz ~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229939 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
