gianny DAMOUR wrote:
I think that deployments should be transactional. For instance, when deploying an EAR to a given cluster, this enterprise archive should be running on each node of the cluster. If the deployment is not possible on a given node, then it seems to be safe to also fail the deployment on the other nodes.
It means that the distribution phase should also be transactional at the cluster level. Furthermore, if one wants to allow pinned-deployments, deployment on a specific node of a cluster, then it means that one should be able to distribute only to a given set of nodes.
Based on these ideas, I think that when distributing a component, one should allow the end-user to choose the target nodes and also provide some convenience methods to choose all the nodes of a cluster.
These capabilites are available through the JSR88 API. When making a distribute() call, the tool provides the plugin (us) with a list of targets to send the module to. This copies the configuration to those nodes but does not start it running. If the distribute operation fails, then the runtime state has not been affected.
It leaves to the provider what the definition of a target is. For example, one vendor could make each node in a cluster a separate target; another could make the cluster the target and then handle internal distribution itself. BEA for example supports both modes: separate nodes and a common central store.
You don't need transactionality for this to work.
So the architecture that I had in my mind for WEBDAV, was a geronimo service that provided a distributed transactional file system type semantics. We would then adapt an existing WEBDAV servlet to talk to this service.
I think that I understand what you had in mind.
I will attempt a second try.
I think a distributed transaction filesystem would be cool - I'd suggest you hook up with Jules Gosnell and James Strachan about what they have planned for the cluster side.
-- Jeremy
