, LLC
http://www.newatlanta.com
> -Original Message-
> From: Robert Munn [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 26, 2005 2:40 PM
> To: CF-Talk
> Subject: Re: Clustering and persistent CFC's
>
> > Ben mentioned in his Blackstone CFUG tour that ser
Yes, programmatically reconstitutable CFCs is a good workaround.
On Wed, 26 Jan 2005 14:35:02 -0500, Adrocknaphobia
<[EMAIL PROTECTED]> wrote:
> I store the init params as a struct in the session scope along with
> whatever CFCs I put in there. When a user gets redirected to a
> different server,
> Ben mentioned in his Blackstone CFUG tour that serializing CFCs will
> indeed be in Blackstone.
>
Is anyone from MACR able to provide official confirmation on this enhancement
being included in Blackstone? This feature alone would provide all the business
justification I need to purchase the l
On Wed, 26 Jan 2005 14:49:35 -0400, Micha Schopman
<[EMAIL PROTECTED]> wrote:
> I thought the issue was more that CFC's cannot be serialized in current
> editions (and thus cannot be transported to another server in the cluster),
> and therefore this also affects server and application scope. So
No, you dont cluster APPLICATION or SERVER scope.
-Adam
On Wed, 26 Jan 2005 14:49:35 -0400, Micha Schopman
<[EMAIL PROTECTED]> wrote:
> I thought the issue was more that CFC's cannot be serialized in current
> editions (and thus cannot be transported to another server in the cluster),
> and the
Correct. The Server and Application scopes only exist on the
hardware/CF instance they're on. They can't move. You can have an
instance of them on every machine in your cluster and your code can
always reference server.myComponent and you'll know it's there - no
matter which server you're on.
T
You are correct, CFC's can't be serialized, which is why they can't
replicate inside sessions. However, there is no such thing as
application-scope replication, so the problem doesn't arise there.
cheers,
barneyb
On Wed, 26 Jan 2005 14:49:35 -0400, Micha Schopman
<[EMAIL PROTECTED]> wrote:
> I t
I think MM uses a setup similar to what I've built any deployed in the
past, involving hardware load balancers using what are called "sticky"
sessions, sticking a user to a specific server for the extent of their
session. If the server fails, those poor saps have to restart their
sessions on anoth
I thought the issue was more that CFC's cannot be serialized in current
editions (and thus cannot be transported to another server in the cluster), and
therefore this also affects server and application scope. So this only affects
session scope?
The CFCs that are presisted in the server scope do not manage any user
specific information. The CFCs manage information that is the same
across all CF Server instances.
That is how CFCs are able to be stored in the server scope in a clustered app.
HTH,
t
On Wed, 26 Jan 2005 20:25:30 +0100, Mi
I store the init params as a struct in the session scope along with
whatever CFCs I put in there. When a user gets redirected to a
different server, I use those init params to recreate thier
components.
-Adam
On Wed, 26 Jan 2005 20:25:30 +0100, Micha Schopman
<[EMAIL PROTECTED]> wrote:
> Sean Co
11 matches
Mail list logo