Hi Siva
Some responses below:
>> In such a case, the RA or JCA or possibly an object representing a
>> collection of Adapters (lets call it a RAFacade) is simply a client
>> component for GMS within a clustered instance. And gets notified
>> when it can participate in the group of instances.And once in the
>> group, the RAFacade can take actions to manage its state and RAs in
>> different instances can talk to each other in a cluster if need be.
>> That said, solution for clustered instance access to a backend EIS
>> could be in found through more than one approach.
> Do we have any samples/documentation showing how components deployed
> in GlassFish [EJB/Connectors] could use GMS to co-ordinate activities
> within themselves in a cluster?
In GlassFish we have components such as transaction recovery, Iiop
failover loadbalancer using Shoal. That may help. Additionally, the
Shoal example uses a mock Application server along with two service
threads named "EJBContainer" and "TransactionService" to demonstrate how
these components in an app server coordinate with each other.
Look here :
https://shoal.dev.java.net/source/browse/shoal/gms/tests/com/sun/enterprise/ee/cms/tests/
more below:
>
>>>
>>> The question really is that, are our clustering infrastructure like
>>> GMS and in-memory replication reusable?
>> GMS is certainly designed for reusability assuming that within a VM,
>> multiple components can use it for their own purposes in a
>> group/collection context. I am not sure I understand how in-memory
>> replication comes into the picture here.
> I think they were wanting some form of in-memory replication to keep
> track of RA state that could be shared across RA instances in a cluster.
Does not seem like a high throughput activity. Shoal provides the
ability to send (and receive) messages to (from) target components in
target instances thus allowing an RA component to address a message to
the group( or individual member) with target component, say "RA". This
is one way to track RA state.
Another way is to use the provided default implementation of
DistributedStateCache which is a shared cache across all instances.
Putting the RA state in the DSC would make it available in all
instances. An RA manager could simply then consult the DSC, for
instance, to find out which RA is in active state.
Caveat: I am not sure if this RA caching is something we should consider
for 9.1 FCS at this late stage. We should take into account testing
resources(or lack thereof) and the riskiness of adding such features
late in the day.
>
> Thanks
> --Siva
>>>
>>> thanks,
>>> Binod.
>>>
>>>> Do you mean Shoal <https://shoal.dev.java.net>GMS ?
>>>> I would need more data to talk about how JCA connectors could be
>>>> clustered.
>>>> Shoal GMS is a generalized component that is independently
>>>> employable in-process in a java application or appserver or any
>>>> component in a VM to group VMs.
>>>>
>>>> glassfish_at_javadesktop.org wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Incidentally, I recently ran into a similar situation.
>>>>>
>>>>> Can the mechanism that the HTTP session replication / SFSB uses,
>>>>> i.e. GSM, memory replication, etc. be generalized so that it can
>>>>> be reused in other components?
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Frank Kieviet
>>>>> http://blogs.sun.com/fkieviet
>>>>> [Message sent by forum member 'fkieviet' (fkieviet)]
>>>>>
>>>>> http://forums.java.net/jive/thread.jspa?messageID=203962
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>