I have made some progress on the persistence functionality for
conversational support in the kernel. Here's a recap:
1. I moved the "store" into spi as that defines the extension
contract for provides that can persist conversational resources (e.g.
component implementation instances)
2. I moved the non-durable store (which uses a HashMap) into core as
this will provide a non-reliable way to track conversational resources
3. I refactored the store spi over several iterations. The biggest
change was making the conversational id more opaque (String instead
of a java.util.UUID). A UUID should probably still be used for
runtime-generated conversation ids (using toString()). The switch to
String makes things a little slower but it will allow us to support
client-provided conversational ids as detailed in the Java C&I spec.
4. I updated the JDBC store to be reliable but very slow
5. I added an initial pass at a journal-based store that uses a
binary log (HOWL). This will provide reliable and fast persistence of
conversational resources. I still need to implement recovery but
transactional writes are enabled. Also, performance improvements need
to be made, particularly w.r.t to serialization but it seems to
support fairly high-throughput given the serialization overhead (on
my laptop 1000 forced writes ~340ms). We face a broader issue
involving how to specify transactional boundaries. For example, if a
client C has conversations going with local services A and B, exactly
when changed state is written to the store. I'd like to have some
type of declarative-based approach, similar to transactional intents
that allow us to specify reliable boundaries.
6. I connected the store to a conversational scope container. Instead
of changing the existing scope container (since I did not want to
disrupt the sample) I created a parallel class ScopeContainerImpl.
The container is a fairly trivial implementation and relies on the
store for most operations. Note that it does not support @Init and
@Destroy since I don't think the latter should be for conversational
implementations (a separate discussion, but the spec will probably
need to be updated).
7. I added two interceptors that will be inserted into invocation
chains between conversational implementations.
ConversationSequenceInterceptor will be inserted into all operations
except ones marked @EndConversation. This interceptor tracks the
conversation sequence the operation is invoked in (start or
continue). This is necessary so the scope container knows whether to
create a new instance or return an existing one (since conversation
ids may be reused). Each operation for a wire receives the same
instance of the ConversationSequenceInterceptor, which is inserted in
the wire post-process phase by ConversationWirePostProcessor. For
operations marked with @EndConversation, a ConversationEndInterceptor
is inserted.
8. Related to 7, I changed the signature of TargetInvoker to account
for conversational sequences
9. I added support for introspecting conversational metadata from
Java annotations, see ConversationProcessor. As part of this,
ComponentType and Operation were updated.
10. In addition to unit tests that are placed alongside tested
classes, I started adding test coverage under integration/
conversation. These tests are intended to verify conversational
execution paths, e.g. start-continue-end.
11. I also made the InvocationHandlers serializable (actually
externalizable). When a component implementation instance is
persisted, the proxy will be serialized with a string (either a
service or reference name). I did make one addition, which is that
InvocationHandlers must also implement SCAExternalizable. This is so
that a handler can be re-associated with its wire on deserialization.
Since wires cannot be serialized, the handler uses the reference or
service name to obtain the wire from its AtomicComponent. The
AtomicComponent is accessed from the current WorkContext, which is
provided through SCAExternalizable (using the WorkContext to do this
instead of just passing AtomicComponent allows the store to remain
decoupled from what the current component is and it allows other
types to be passed through for deserializing different entities).
This process of re-associating wires is fairly slow but I don't think
it will have much of a performance impact as the memory store never
serializes and the journal store only does so in the event of
recovery (it maintains a cache of active instances). We will have to
extend ObjectOutputStream.resolveObject(Object obj) to handle this.
As next steps, we will need to to get these pieces integrated with
the overall conversational infrastructure, particularly interaction
with bindings. We should also take a look at implementing more of the
SCA client API, such as ServiceReference.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
