[jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1002) EJB3-based version of the RetryInterceptor

[Brian Stansberry (JIRA)]

    [ https://jira.jboss.org/jira/browse/EJBTHREE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12471085#action_12471085 ] 

Brian Stansberry commented on EJBTHREE-1002:
--------------------------------------------

Some notes on this as I've been thinking about it a bit.

Assumption is that the basic EJB2 design of storing the cluster topology in JNDI next to the bean ref, using jndiname + fixed_suffix is followed. (That assumption is open to debate if there are better approaches.)

JndiClusteredSessionRegistrarBase would override superclass bind() method to bind the cluster topology objects in JNDI. Objects would either be a FamilyWrapper, or a Reference with a bunch of StringRefAddr, one per target, and an ObjectFactory to create the FamilyWrapper on the client side.

SessionClusteredProxyObjectFactory.createProxyFactoryProxy would be modified to pass the jndiname to ClusteredPojiProxy via a new property setter. Field for this would be transient to ensure serialization format is unchanged. ClusteredPojiProxy would add this name to the invocation metadata.

The actual retry interceptor would be much like the current one, except than once it has created a FamilyWrapper it doesn't need to bind it to the invocation, since FamilyClusterInfo/ClusteringTargetsRepository ensure there is only one set of targets per family.

> EJB3-based version of the RetryInterceptor
> ------------------------------------------
>
>                 Key: EJBTHREE-1002
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1002
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>
> Looking for a conceptual equivalent to the EJB2 RetryInterceptor -- ability to reestablish a valid remoting client when the current FamilyClusterInfo does not contain any valid targets.
> If the approach is analogous to the RetryInterceptor case, what would be registered in JNDI is the FamilyClusterInfo itself (rather than the EJB2 Invoker). Looking this up in JNDI would provide the current list of targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira