Millies, Sebastian wrote:
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
According to the SCA-J specification:
Where an implementation is used by a "domain level component", and the
implementation is marked "Composite" scope, the SCA runtime MUST ensure
that all consumers of the component appear to be interacting with a
single runtime instance of the implementation. [JCA20004]
Where an implementation is marked "Composite" scope and it is used by a
component that is nested inside a composite that is used as the implementation
of a higher level component, the SCA runtime MUST ensure that all consumers of
the component appear to be interacting with a single runtime instance of the
implementation. There can be multiple instances of the higher level component,
each running on different nodes in a distributed SCA runtime. [JCA20008]
The SCA runtime can exploit shared state technology in combination with other
well known high availability techniques to provide the appearance of a single
runtime instance for consumers of composite scoped components.
The key phrases here are "...appear to be interacting with a single runtime
instance..." and "...provide the appearance of a single runtime instance..."
The current Tuscany implementation uses a single runtime instance. However,
the SCA-J specification permits the use of multiple instances as long as the
appearance of using a single instance is maintained. This means that you can
safely write code that assumes a single instance, as any SCA implementation
that uses multiple instances would need to fully emulate the appearance of
having a single instance with respect to any code that you have written.
Simon
