On Friday, August 29, 2003, at 01:16 pm, Alex Blewitt wrote:
On Friday, Aug 29, 2003, at 12:59 Europe/London, Daniel S. Haischt wrote:
Alex Blewitt wrote:
[...]
You also have to consider the case when a clustered system is in operation. Then, they are likely to need to share data that is installed, and a sensible back-end may need to synchronize such writes across a number of nodes/clusters.
I agree for a single-server environment, having an in-memory cache will be the fastest, but having a switchable JNDI server will allow both :-)
is there already someone working on a clustering solution?
sometimes i am wondering whether we are aiming to provide a all-in-one wonder. wouldn't it be possible to start with a more simple in-memory solution and switch to a more complex solution while Geronimo emerges?
Geronimo is currently a single-node system. It would obviously be desirable to support clustering at a later stage.
However, thinking about the aspects involved in clustering now, it allows us to make better abstractions which will allow us to migrate to a clustered solution easier in the future.
There are many forms of clustering. Off the top of my head this includes...
* JNDI clustering (either peer based or LDAP style master-slave model)
* clustered caching (a big topic in and of itself) used for all kinds of things from arbitrary application data to CMP / JDO caching
* clustered HTTP / session bean state (similar in some ways to the above with some differences - typically sticky-ness)
* clustered servers - e.g. deploying a WAR / EAR to the cluster & it runs everywhere in the cluster etc
* clustered JMS implementation (using clustering for persistence for HA to avoid message loss)
I'd hope we can implement them all in some modular & configurable way so users are free to pay whatever cost (in RAM, I/O, CPU, complexity or whatever) they are happy with to get the quality of service they need in all aspects of Geronimo.
James ------- http://radio.weblogs.com/0112098/
