Hi Legolas,
>
> I have another question which is a bit more technical.
>
Sure! I think all of your questions are equally technical :)
> What is Glassfish mechanism for session, JNDI,... replication?
>
Session replication is done using in-memory session replication
mechanism in case you choose to do it. This type of session
persistence is termed as "replicated" and uses Shoal to
replicate the session data across instances. Shoal in turn
uses JXTA as the low-level mechanism.
For you, as an application programmer, it will suffice to know that:
- When you create a cluster-profile domain, by default
web container and ejb container implementation knows that
it has to make sure that the session is persisted in *all
the instances in the cluster*, so that instances know the
latest state. Thus, if you communicate with a web-container
in instance-1, then any changes made to the HTTP Session
are available to instance-2 as well, assuming cluster has
instance-1, instance-2 ... and all of them are running.
As far as JNDI is concerned, there is a JNDI implementation
in each server instance in a cluster. You deploy your resources,
EJB's etc. to a cluster which means to all the instances in
a cluster. Thus all the entities that are looked up are
available in all the server instances. There is no federated
JNDI, it is individually maintained and updated in a given
server instance.
This works well with the management infrastructure in GlassFish.
For example, if you have a cluster of instances, your target of
management is a cluster and not individual instances! In other words,
if you have cluster1 = {instance1, instance2, instance3}, then
- you have to deploy an application to the cluster1.
- you have to create any resource (JDBC, JNDI, Mail, External etc.) only
on cluster1.
- you *can not* deploy an application to either instance1 or instance2
or instance3. Same for resources.
Bottom line: Management Infrastructure makes sure that cluster configuration
is homogeneous.
> for example does it replicate all information into all instances
> memory or it store them in one central shared memory and other
> instances read from that memory?
>
Well, you can (in theory) write your own high-availability persistence
implementation that does exactly that. Then, the web-container and
ejb-container
will delegate the persistence to your code rather than the built-in
in-memory replication.
A configuration of GlassFish server is using Sun's HADB software. When
using that, it is possible that the session is state is stored in a highly
available database for retrieval by instances in the cluster.
Hope this helps.
Regards,
Kedar
> Thanks
>
>
>
> kedar wrote:
>> I don't think clusters failing over other
>> clusters is a good idea, because it will be
>> hard to maintain consistency. If you have
>> enough hardware, just create a cluster with
>> instances in it and go on increasing its
>> capacity in terms of scalability.
>>
>> Few Guiding Principles:
>>
>> - All instances in a cluster are homogeneous as far as
>> configuration and applications/resources are concerned.
>> In a given set of instances in a cluster, there is
>> an inherent ability to fail over to each other, maintaining
>> the state.
>>
>> - All clusters are individual sand-boxes and are designed
>> to operate independent of others and GlassFish infrastructure
>> does not have a built-in capability to fail over across
>> clusters for aforementioned reasons.
>>
>> Kedar
>>
>>
>> Daniel Cavalcanti wrote:
>>> Just a thought.
>>> You could implement your own load balance plugin to do that. Instead
>>> of having the DAS start the "other" clusters, have all NA's and
>>> instances already running and make your load balancer treat certain
>>> instances as part of cluster A, B, or C. The SJSWS plugin file comes
>>> with a sample round-robin load balancer source code. It's a little c
>>> program (shared library) you need to write. You only have to
>>> implement to methods.
>>>
>>> Daniel.
>>> On 4/21/07, *Legolas Woodland* <legolas.w_at_gmail.com
>>> <mailto:legolas.w_at_gmail.com>> wrote:
>>>
>>> Hi
>>> Thank you for reading my post, any comment for this?
>>> if this functionality is not present, is there any plan to add
>>> this functionality to glassfish?
>>> Thanks
>>>
>>> On 4/19/07, *Legolas Woodland* <legolas.w_at_gmail.com
>>> <mailto:legolas.w_at_gmail.com>> wrote:
>>>
>>> Hi
>>> Thank you for reading my post.
>>> is it posible that DAS start a second cluster after one
>>> cluster failed?
>>> for example we have 3 cluster, each cluster has 3 node agent
>>> and each node agent has 2 instances.
>>> Now i want to have something like:
>>> By default cluster one is under heavy load.
>>> if cluster one failed by any means (disaster, power
>>> shortage....) DAS start cluster two.
>>> All instances are configured to work with sun java
>>> web server
>>> load balancer plugin. <==== I know how to configure load
>>> balancer using that loadbalancer.xml file.
>>> Thanks.
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>