I have committed changes to integrate this infrastructure, specific comments inline.
On 11/27/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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.
I changed the creation of a new conversation id to create a String. 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).
I replaced the existing conversational scope container with this new parallel one (and removed the parallel one). This required the ConversationalScopeObjectFactory to get a Store instance to pass to the new instance of the scope container it creates. To achieve this I autowired a Store constructor parameter and also added a store component to system.scdl, implemented by MemoryStore. This will probably need to change when the scope container also gets a durable store instance. Notice that when MemoryStore is autowired the loader throws an IllegalPropertyException on getExpirationOffset, I commented out the property annotation as I am not sure what the intent here is, I will raise a JIRA to track this. Since the scope container does not support init and destroy, some of the original test cases that deal with life cycle were failing; I commented out the tests for inits and destroys in these tests: - BasicConversationalScopeTestCase - ConversationalScopeRestartTestCase, and - ConversationalScopeInstanceLifecycleTestCase 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.
I added ConversationWirePostProcessor to core/implementation.scdl to allow these interceptors to actually be added to the wire. 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]
