Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory-Database/-cache #5

Open
Idrinth opened this issue Sep 17, 2016 · 7 comments
Open

Memory-Database/-cache #5

Idrinth opened this issue Sep 17, 2016 · 7 comments
Assignees

Comments

@Idrinth
Copy link
Member

Idrinth commented Sep 17, 2016

Opinion Maurice:

For state handling i would prefer Apache ignite. Memchached client protocol is supported, it is distributed and clusterable, It integrates good with bigdata frameworks and hibernate and can handle ACID, can also do messaging, grid, streaming and events. You can connect to Ignite using a Memcached client in one of the following languages: PHP Java Python Ruby

Maybe i could write a native Thrift adapter like i did for the KIE Server.

Resources:
https://en.m.wikipedia.org/wiki/List_of_in-memory_databases

In general memcached can also use multiple servers, but does not replicate data in between, something that might lessen the traffic required to keep the systems up and running.

Currently we don't have anything requirering a state to be reliably avaible, but I do see benefits in using AI for a theoretical future, where the state must not be lost.

@Maurice-Betzel
Copy link
Contributor

I have missed one more thing, it runs on Karaf 4.x. This is my main modular runtime for Java and i have a working build to integrate Ignite in. Meaning the Maven build generates a Karaf deployment zip or tar having all dependencies. Also great for cloud deployment. After extracting and startup everything gets installed automatically including config.

@Maurice-Betzel
Copy link
Contributor

Regarding state handling, every session has one active view that consists of several active controllers.
Lets say i select several entries in a displayed list, that state must be handeld at best by the controller of that list in persisting a list of selected list models.

@Idrinth
Copy link
Member Author

Idrinth commented Sep 18, 2016

technically I'd assume every session is a list of objects, so every controller would be able to add his own object to that list, without needing to adjust any other controller's data - or even have a chance to do that.

I assume that with running on Karaf you mean, that there's a pre-build or deploy-ready version of it from the start?
In general I have no issue with using AI - it is at the very least more reliable on it's own.

@Maurice-Betzel
Copy link
Contributor

Lets look at the relation of session and mvc. One user has one session with one active, lets call it master view (template) containing many views, each displaying a part of the business model through a controller. Am i right sofar? If controllers need to keep track if each others updates there has to be a listener/update event functionality which can retreive the state of a other controller. So how state is stored should be based on functionality.

Concerning AI, Ignite is a in memory datafabric that integrates well with Hadoop, Kafka and what not in the big data arena. It is OSGi ready, meaning i can deploy it on Karaf. I have a Karaf build with complete ESB capabilities that can be outfitted with it. IT just unpacks and starts it. This Karaf build is vomplete modular and can be prefitted how you want it.

@Idrinth
Copy link
Member Author

Idrinth commented Sep 18, 2016

So no reason not to use it, feel free to make it official, @Maurice-Betzel :)

@Idrinth
Copy link
Member Author

Idrinth commented Sep 18, 2016

I doubt, that the controllers will (usually) need to track another controller's status, with the exception of a login-status type controller, that should be refered to by most other controllers.

@Idrinth
Copy link
Member Author

Idrinth commented Sep 18, 2016

Regarding Acid, I think we need it whenever there is a task that might change anything - we should make sure there are none-blocking, read-only options avaible as well.
I really don't want to diff-merges between differently modified session parts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants