Yes Sean this is exactly what I needed to see, thanks.  One further
question though.  In the pseudocode you wrote, you are actually showing
exactly what I had in mind, that the listener holds a session variable
which contains a shopping cart instance.  I probably didn't describe
that well enough in my last message.  But we're getting close to the
core of my question/confusion.  Assuming you had some additional logic
in your conditional check, like this:

listener (pseudo-code):
        function addToCart(product) {
                if (not structKeyExists(session,"cart"))
                        session.cart = createObject("component","cart");
                        session.cart.addProduct(product);
                else
                        session.cart.addProduct(product);  // should
this be locked?
        }

Don't you have to lock the single call to "session.cart.addProduct()"?
It's in the session scope, and it seems to me that another thread could
possibly be reading or writing to this via the listener, so shouldn't it
be in an exclusive lock?  And then shouldn't other reads of the cart (ie
"session.cart.getCart()") have readonly locks?

Thanks again, we've boiled it down to exactly where my real question is.

Brian  

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield
> Sent: Thursday, December 04, 2003 12:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Basic CFC Design Question
> 
> No - instance variables in listeners won't do you any good since they 
> are in application scope. The fa�ade *manages* the cart in session 
> scope.
> 
> listener (pseudo-code):
>       function addToCart(product) {
>               if (not structKeyExists(session,"cart"))
>                       session.cart = createObject("component","cart");
>               session.cart.addProduct(product);
>       }
> 
> The cart CFC is standalone (i.e., independent of the Mach II 
> framework).

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to