Hi, As we've discussed on various occasions, we're looking at allowing people to use the toolkit with their own types in express mode.
Let's summarize the current design: The Terracotta clustering toolkit works by isolating itself through a dedicated classloader hierarchy in which it can perform byte-code instrumentation and launch an L1 client. This isolation is performed through the StandaloneClusteringProvider for the application developers and TIM developers are supposed to create a similar class loading gateway (StandaloneTerracottaClusteredInstanceFactory for tim-ehcache), but the latter is out of scope for this discussion. This context is private and supposed to be responsible for loading all the classes that enter it for several reasons: * byte-code manipulation at class definition time requires control of the class loading process * these classes can't be accidentally loaded by several classloaders * classes refer back to the active L1 that was started for this context and this allows multiple L1s to be started or shared for an application context (when an express client is started with the same L2 URL, it will be shared amongst express modules, otherwise it's isolated) To ensure this, the toolkit runtime exposes public types outside of the StandaloneClusteringProvider only as interfaces and the implementations are actually stored as a separate jar within the runtime jar. This prevents the classes to be loaded by the application classpath and developers to accidentally instantiated them. The express toolkit classloader is able to find this embedded jar and properly get the required types out of there. It also knows about the public interface types and always delegates the loading to the application classloader. So to create a new instance of a particular clustered toolkit type, application developers now do: BlockingQueue queue = clusteringProvider.getBlockingQueue(name) Which BlockingQueue is such a public interface and the name is used to keep track of the identity of the instance across the cluster. The problem: The queue instance above functions perfectly as a clustered queue, but it can only store literal types or objects that were instantiated through the clustered provider. Obviously, app devs would like to be able to store their own types in there. An important question for this is: What are real-world use-cases to use the express toolkit like this? Here are a couple of possible technical ideas to make this possible, but they only serve as a starting point for the discussion. * require app devs to bundle their custom types in a dedicated jar also and to only reference them through interfaces, allow us to use the same approach as the one we're currently using => the huge downside is that they'll most like have to restructure their data structures and most importantly they will have to go through a generic factory method and not be in control of the lifecycle of instances of these types * create an instrumentation agent that can instrument the byte-code of the classes without having to use a classloader => the problem here is that these types currently can find their relevant L1 client for the clustering logic, maybe some creative ideas here might make this possible, not sure * forget about cluster-wide object identity and create a generic serialization/deserialization approach that would allow types that aren't serializable per-se to still be clustered => this would obviously lose cluster identity but also be limited to whatever we support in this serialization/deserialization logic, it might also introduce one more concept of app devs that they need to understand * ... Thanks for reading this far and I hope this made some sense. Please don't hesitate to ask further questions and please shoot out your ideas and use-cases! Thanks, Geert -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
