|momentary service disruptions. Also, you don't want half-completed |configuration changes to start getting used - you want them to finish |first. I'm just saying this point of view on requirements (if they are
Yes, the transactional nature of the distributed administration operation might be real.. I don't know. |indeed desirable, I don't really know) is satisfied really well by the |versioning transaction model of firebird/interbase: transactions get |numbered as they come in, so you can tell from the log what order they |happened in, and configuration changes are invisible to all transactions |(invocations) that start before the configuration change commits, whereas |those after the commit use the new configuration. Conceptually this seems What is the problem with numbering the result of the operation. I.e. there is a state that exists in the MBeans after the invocation and for making the store() backed by an EJB we will buy you the transactional XA registration of the database connection that stores that configuration. Building an history in the database based on the state is disconnected from the incoming invocations. Are you saying the incoming invocations should be recorded? Do you know how big this will get? will you always get the tools to replay this scenario? I would rather work with state in MBean and possibly both if we want to be rich (store the invocation with the modification ... pffff) clearly heavy and applicable to management operations only. |cleaner to me than the "valves" you were talking about to stop MIs during |reconfiguration. Only it doesn't really apply to the same stuff or does it? One is storing the state of the MBean in the database (it's configuration) with many other MBean nodes so you update your machine at once but what does it have to do with stopping the threads coming in? marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
