[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