Project: mule
Issue MULE-7989: Discussion on user-managed objectstore to define what is needed
there 3 categories of needs: 1) Using ObjectStore as a user database - with queries, transactions, etc. 2) Using ObjectStore as a user key value store - e.g. for lookup tables, caching, connector oauth tokens, etc 3) Using ObjectStore for application state - e.g. idempotent router, until successful, etc. #1 is NOT a goal and I don't think we should spend a single cycle on this. People can use databases for that. If, at some point, we have time to do this - we can look at it. If anyone feels differently about this, ping me on slack and I can explain in more depth. For #2 and #3, we identified a few areas that need to be addressed. I am summarizing the discussion between Pablo and I, so some of this address part of the solution and not the problem :). I think it's all open for debate FWIW. We need to clarify the semantics around persistence and clustering for ObjectStores. We identified 3 different modes that we need to support clustered + persistent, clustered + non-persistent. Right now, CloudHub implements clustered + persistent, while ESB implements clustered + non-persistent. Either we need to make this more explicit inside the ESB or remove one of the modes. Also, the two different modes have very different availability characteristics on cloudhub, so it's important to know what type of persistence a component is selecting. Partionable object store stuff is currently very messy. it's supposed to be an internal semantic, but it gets exposed to consumers (e.g. routers). ObjectStoreManager shoudl be handling naming/partitioning underneath the covers. If not, this ends up being a layer on top of ObjectStores, and it becomes harder to build a management interface around it. Key-value store use cases require an update method. We need to document the consistency model - e.g. write last wins We need an ObjectStore which can use the new database connector for on-prem customers. We need an easy way for users to specify new object stores via XML which get created via the ObjectStoreManager. Use case here is that I want to specify an objectstore specifically for my cache which has a specified TTL and maximum # of values. I don't believe this is possible right now. (rinse and repeat for any other mule component) Pablo Abad - we didn't talk about #6, but I thought of it while writing this up, so just capturing it. Please let me know your feedback on this. Acceptance criteria: * create jiras for tasks associated to creation of this feature
Story points: 8