[jboss-as7-dev] EJB Remote client design

David M. Lloyd david.lloyd at redhat.com
Wed Sep 21 10:10:41 EDT 2011


On 09/21/2011 08:50 AM, Jaikiran Pai wrote:
> On Thursday 15 September 2011 09:20 AM, David M. Lloyd wrote:
>>
>> Each EJB receiver has an obligation to keep the EJB client context
>> updated with the list of module identities that it can access.  When a
>> proxy is invoked upon, the EJB client context uses this table to select
>> the destination.  This means that for the Remoting protocol for example,
>> the server sends back messages informing the client of changes in
>> deployment status (which should be relatively infrequent) as well as
>> sending an initial summary of what modules are available.

> If we solely rely on the EJB module inventory on the client side to
> select the right server target for a proxy, would it not introduce a
> problem where the module inventory (on the client side) might not yet
> have been updated by the server side when the user code invokes on the
> proxy? For example, a server might be hosting 10 EJB modules and it
> might be in the process of sending that module availability report to
> the client, when the client might invoke on the proxy. That would result
> in a spurious "target not available" for the invocation, even though the
> beans are hosted on the server.

If you're talking about the case where a deployment happens just as an 
invocation occurs, the window between the time the server deploys and 
the client hears about it is so small that you're not really losing 
anything.

If you're talking about the undeploy case, we have only to ensure that 
the notifications are sent before the undeploy happens (using 
dependencies for example) to minimize this case, and if it turns out to 
be impossible to make it race-free then it should be possible to 
redirect the invocation to another node (if any exists).

-- 
- DML


More information about the jboss-as7-dev mailing list