Hi there,

I am going back to an old discussion we had in December, and
which I've just had occasion to revisit.

I wonder if I'm reading too much into the following statement
of Simon Nash's:

> -----Original Message-----
> From: Simon Nash [mailto:[email protected]]
> Sent: Friday, December 10, 2010 10:21 AM
> To: [email protected]
> Subject: Re: Elementary question about Scopes

[snip]
 
>  With COMPOSITE scope, the SCA runtime
> can control the creation and lifetime of the COMPOSITE instance rather
> than being at the mercy of what the JVM does.  If the domain is entrely
> contained within a single JVM, this distinction may not be important.
> For other scenarios such as a server cluster or a distributed domain,
> there will be multiple Java instances of the same SCA COMPOSITE-scoped
> object, with updates coordinated by the SCA runtime. it is essential
> that
> the SCA runtime has the ability to manage this situation and give all
> the JVMs the appearance of a single shared COMPOSITE-scoped object even
> though the actual physical reality might be somewhat different.

Now, I've just finished coding a COMPOSITE scoped component that is
supposed to serve as a sort of global registry for some kinds of
objects (somewhat akin to a server that would coordinate locks on
business objects). This component also contains some rather fine-grained
synchronization on internal data structures for optimized concurrency.

I wonder how the SCA runtime would be able to "coordinate updates" in
view of this. Can I (should I?) ensure that it is really ALWAYS THE
SAME INSTANCE of the component that requests are directed to, even in a
cluster?

I am also not clear about how distributed domains come into the picture.
I had thought the point of a distributed domain was to have several DIFFERENT
composites run in the same domain in different JVMs, even on different servers.
Simon's message makes it sound as if I would distribute the SAME component
over several JVMs.

-- Sebastian


Reply via email to