Clustering the Application Scope

dev google-group-archive
1

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe below.
As many of you may know it is possible to cluster the session scope and
store it in a sessionstore which can be either a database, a cache or the
file system. Now often people have applications in a cluster that need to
stay in “synch”. So for instance if you reinit an application on one server,
you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way the

session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized for
every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but only
if the request has finished and the value has been rewritten to the storage

§ Serialization and deserialization can be time consuming, since people
tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that the

application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part of the
application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by not
overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key is
set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are only
allowing serializable values.

This idea is lingering with us for a while already and we could have used it
in many occasions. I am very intrigued by it and I would appreciate your
thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: mailto:Gert_Franz @Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

2

+1 for clustering a subkey.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 2/27/2015 8:56 AM, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session
scope and store it in a sessionstore which can be either a database, a
cache or the file system. Now often people have applications in a
cluster that need to stay in “synch”. So for instance if you reinit an
application on one server, you should initialize all others in the
cluster too. So Micha and I discussed already a while ago what options
(back then for Railo) are available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized
for every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to
the storage

§ Serialization and deserialization can be time consuming, since
people tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that

the application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part
of the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced
by not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the
key is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server,
until the next request on any other server might read the application
scope from the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have
used it in many occasions. I am very intrigued by it and I would
appreciate your thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz mailto:Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

3

I wonder whether a mysql style binary log could be the approach or actually
just making events that could be listened for by individual nodes to know
that certainly keys in the scope are dirty and need to be reinited rather
than worrying about how to deal with complex objects. To me events would
go along way with this

ASent from my phone
On 27 Feb 2015 19:48, “Alex Skinner” <@Alex_Skinner> wrote:

Pretty sure I made a feature request for this back in the railo days.
definitely sub keys rather than whole scopes.

Also id be interested in whether a sync of data similar to how elastic
search does it should be used rather than external cache store. I’d be
worried about Latency for app scope. Also I think its fair to say that
typically for most people app scope it’s read many write far less where as
session is far more down to the app.

Cheers

A

Sent from my phone
On 27 Feb 2015 19:41, “Michael van Leest” <@Michael_van_Leest> wrote:

+1 subkey, but would prefer a separated cluster scope. I’ve seen
something about cluster scope in the past.

On Friday, February 27, 2015, Igal @ Lucee.org <@Igal> wrote:

+1 for clustering a subkey.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 2/27/2015 8:56 AM, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session scope
and store it in a sessionstore which can be either a database, a cache or
the file system. Now often people have applications in a cluster that need
to stay in “synch”. So for instance if you reinit an application on one
server, you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized
for every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to the
storage

§ Serialization and deserialization can be time consuming, since
people tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that

the application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part
of the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by
not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key
is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have
used it in many occasions. I am very intrigued by it and I would appreciate
your thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
Sent from Gmail Mobile

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAMaJE6sfk_j2YT9-R94s-XETfPcycifvM67D0-_YvN_N1dKJ2w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAMaJE6sfk_j2YT9-R94s-XETfPcycifvM67D0-_YvN_N1dKJ2w%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

4

+1 subkey, but would prefer a separated cluster scope. I’ve seen something
about cluster scope in the past.On Friday, February 27, 2015, Igal @ Lucee.org <@Igal> wrote:

+1 for clustering a subkey.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 2/27/2015 8:56 AM, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session scope
and store it in a sessionstore which can be either a database, a cache or
the file system. Now often people have applications in a cluster that need
to stay in “synch”. So for instance if you reinit an application on one
server, you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized for
every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to the
storage

§ Serialization and deserialization can be time consuming, since people
tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that the

application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part of
the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by
not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key
is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have used
it in many occasions. I am very intrigued by it and I would appreciate your
thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz <javascript:_e(%7B%7D,‘cvml’,‘@Gert_Franz’);>
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
Sent from Gmail Mobile

5

Pretty sure I made a feature request for this back in the railo days.
definitely sub keys rather than whole scopes.

Also id be interested in whether a sync of data similar to how elastic
search does it should be used rather than external cache store. I’d be
worried about Latency for app scope. Also I think its fair to say that
typically for most people app scope it’s read many write far less where as
session is far more down to the app.

Cheers

ASent from my phone
On 27 Feb 2015 19:41, “Michael van Leest” <@Michael_van_Leest> wrote:

+1 subkey, but would prefer a separated cluster scope. I’ve seen something
about cluster scope in the past.

On Friday, February 27, 2015, Igal @ Lucee.org <@Igal> wrote:

+1 for clustering a subkey.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 2/27/2015 8:56 AM, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session scope
and store it in a sessionstore which can be either a database, a cache or
the file system. Now often people have applications in a cluster that need
to stay in “synch”. So for instance if you reinit an application on one
server, you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized for
every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to the
storage

§ Serialization and deserialization can be time consuming, since people
tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that

the application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part of
the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by
not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key
is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have used
it in many occasions. I am very intrigued by it and I would appreciate your
thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch
https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org
https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
Sent from Gmail Mobile

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAMaJE6sfk_j2YT9-R94s-XETfPcycifvM67D0-_YvN_N1dKJ2w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAMaJE6sfk_j2YT9-R94s-XETfPcycifvM67D0-_YvN_N1dKJ2w%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

6

yes! subkey!On Friday, February 27, 2015 at 8:56:13 AM UTC-8, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session scope
and store it in a sessionstore which can be either a database, a cache or
the file system. Now often people have applications in a cluster that need
to stay in “synch”. So for instance if you reinit an application on one
server, you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized for
every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to the
storage

§ Serialization and deserialization can be time consuming, since people
tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that the

application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part of
the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by
not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key
is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have used
it in many occasions. I am very intrigued by it and I would appreciate your
thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz <javascript:>
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

7

I wrote a wrapper for Infinispan ages ago-- that bad boy would fit this
bill, and a few of the other “that would be neat to have” neat to haves
mentioned in this thread.

Big fan of stuff like JMS, over say adding a scope that we can’t set up
for push, pull, poll, whatnot types of scenarios.

I love to leverage tools like that which already exist, and are used in
heavy-duty contexts (mission critical type stuff), vs. rolling new
implementations, that then need to get battle tested. Not that you
don’t need to battle-test how things are glued together, too, but when
the core is some beastly solid thing… :slight_smile:

-DenOn 2/27/15 12:54 PM, Igal @ Lucee.org wrote:

+1 for events that can be intercepted in Java and thus allow for easy
integration with other systems and develop new tools as needed.

8

I am not sure if I would be a big fan of clustering the application scope.
I think the concern of having a local JVM memory space is useful and
separate from a clustered environment. For having a clustered storage,
well, that’s why you have clustered caches that you can easily connect
already to Lucee like Couchbase, Infinispan, etc. I would not want my
cfc’s or anything I put on application scope to be serialized across the
wire even though you could set serializable = false on them.

I think the attractiveness is to have the applications communicate with
each other instead of trying to do communications via the application
scope. Message queues, websockets and AMQP standard messaging protocols
might be a more suited avenue that could be abstracted into Lucee in such a
way where an application can have inter-cluster communications. Where you
can issue one event in one instance and it can propagate in the cluster.
RabbitMQ is fantastic at it and very easy to integrate.

So I am more in favor of inter-cluster communication, than application
storage distribution. My 2 cents.On Friday, February 27, 2015 at 8:56:13 AM UTC-8, Gert Franz wrote:

Hello all,

I just wanted to have everyone’s opinion on the idea I will describe
below. As many of you may know it is possible to cluster the session scope
and store it in a sessionstore which can be either a database, a cache or
the file system. Now often people have applications in a cluster that need
to stay in “synch”. So for instance if you reinit an application on one
server, you should initialize all others in the cluster too. So Micha and I
discussed already a while ago what options (back then for Railo) are
available.

I just wanted to throw out the following ideas:

  •      Cluster the complete application scope just in the same way

the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o Pros

§ Easy to implement as a user

§ A pointer from the session scope to the application scope would be
possible again

o Cons

§ Singletons are serialized as well so they have to be deserialized for
every request (if applicationcluster is set to false)

§ Values are not immediately available if a request sets a value, but
only if the request has finished and the value has been rewritten to the
storage

§ Serialization and deserialization can be time consuming, since people
tend to store a lot in the application scope

  •      Cluster a subKey of the application scope. This means that the

application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the
application.cluster key and all values below are stored in the
applicationstorage

this.applicationcluster = true|false;

o Pros

§ The higher performance would be useable for the non-clustered part of
the application scope

§ No serialization necessary

§ Since only a subset is clustered, the performance can be enhanced by
not overloading the clustered key with data.

§ The complete application scope would still be clusterable if the key
is set to “”.

o Cons

§ None that I can see

A general con is, that variables set on one server in a clustered
application scope are not immediately available to any other server, until
the next request on any other server might read the application scope from
the storage.

Obviously the keys in the clustered parts of the application scope are
only allowing serializable values.

This idea is lingering with us for a while already and we could have used
it in many occasions. I am very intrigued by it and I would appreciate your
thoughts.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: @Gert_Franz <javascript:>
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

9

What happened with the paid cluster scope extension? I thought we already had this functionality, although I have never used it.

I like keeping the consistency of different scopes when dealing with different lifetimes. To me, a separate cluster scope is clear when compared with application, request, session, server, lifetimes.

I could see the usefulness of clustering the application scope, then one can think of the cluster as the application lifetime. Maybe you can have both options, cluster the application scope and accept the drawbacks, or use a cluster scope. I don’t however see the clarity in having application.cluster.

I also like the idea do being able to call the cluster cache directly, cacheput() cacheget() etc. I think the scopes are syntactic sugar and useful, but we don’t need to necessarily hide the implementation for those that want that.