-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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. |
Regarding state handling, every session has one active view that consists of several active controllers. |
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? |
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. |
So no reason not to use it, feel free to make it official, @Maurice-Betzel :) |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: