[jboss-as7-dev] DataSource Enable/disable

Brian Stansberry brian.stansberry at redhat.com
Mon Apr 25 12:03:19 EDT 2011


Yes. That's one reason I prefer modeling this as a state transition 
rather than a state.

On 4/23/11 2:46 AM, Dimitris Andreadis wrote:
> I think 'disabled' carries the wrong meaning. Isn't 'disabled' really what we have been
> modeling as 'stopping' ?
>
> On 21/04/2011 16:08, Brian Stansberry wrote:
>> I think it would be useful to separate states, state transitions, and
>> user interface actions.
>>
>> One way to model this is to say the states are:
>>
>> started -- accepting all requests
>> disabled -- accepting all requests associated with existing work (in
>> this case "existing work" == uncommitted transactions for which the DS
>> has done work) but rejecting all other requests
>> stopped -- not accepting requests
>>
>> The user interface actions are to trigger a transition between those
>> states. When the service is in the "disabled" state, the user monitors
>> it for the # of open transactions and then moves it to the stopped state
>> when conditions are acceptable. If the user doesn't wish to go to that
>> effort, their initial action triggers a direct move to "stopped" which
>> results in non-graceful behavior.
>>
>> The negative to this approach is if the default workflow is to
>> gracefully get from started to stopped, the user has to take a number of
>> actions to get there.
>>
>> Another way to model this is to see "disabled" as the behavior of a
>> service that is *transitioning* from "started" to "stopped". The end
>> goal for the user is always to get to "stopped", and the default is for
>> that to be graceful. The extra user interface action needed here then is
>> the ability to force the service to abandon the attempt to be graceful
>> and proceed directly to "stopped." This is doing by adding an overloaded
>> variant to the action that triggers the move to "stopped" that accepts a
>> timeout. A timeout of 0 means don't spend any more time trying to be
>> graceful. (Perhaps so syntactic sugar like "stop-now" could be laid on
>> top of the 0 timeout.) The overloaded variant can be used as the initial
>> action (if the user knows how long they are willing to wait) or to force
>> an ongoing transition to "stopped" to complete.
>>
>> This latter approach is how we're trying to do things in AS 7. This has
>> mostly been discussed in the context of server shutdowns, but the way
>> the individual service implementations would handle it should allow same
>> workflow to be applied on a more fine grained basis, if the subsystem
>> developers choose to expose it.
>>
>> On 4/20/11 8:34 PM, Jim Tyrrell wrote:
>>> But in a clustered example you could fail over to another node that
>>> still had that service available, so you would not get errors.
>>>
>>> What if you wanted to gracefully update a datasource, what do you
>>> purpose? To keep as near to 100% uptime as possible. IE the database has
>>> not changed, the app has not changed, but in the back is a Oracle RAC
>>> that can now handle double the amount of threads? You have four machines
>>> that need to be updated.
>>>
>>> I would think you would want to disable the node datasource, then stop
>>> the node datasource. Edit the config, and then start it back up, along
>>> with some pretty tooling that lets you know no more transactions are
>>> pending on that datasource before you stop it. In a perfect world this
>>> is all automated in some tooling to give you 100% uptime and quicesing a
>>> server.
>>>
>>> I fail to see how the paradigm of the web container load balancer does
>>> not apply, I freely admit I am stupid, but your answer to me confirms
>>> that it would apply.
>>>
>>> Jim Tyrrell
>>> Senior JBoss Solutions Architect
>>>
>>> Did you see RHT on CNBC's Mad Money?
>>> http://www.cnbc.com/id/39401056
>>>
>>>
>>>
>>> On Apr 20, 2011, at 5:29 PM, David M. Lloyd wrote:
>>>
>>>> Graceful shutdown will probably have to work somewhat differently than
>>>> that. Generally the service simply stays available until nothing is
>>>> using it (or depending on it) anymore. For example if I have a data
>>>> source being used by 3 EJBs, the data source is available until all the
>>>> EJBs are shut down and/or undeployed. And the EJBs are available until
>>>> all their clients are shut down and/or undeployed, and so on down the
>>>> line.
>>>>
>>>> Having services start refusing requests makes shutdown be not very
>>>> graceful - it generally just results in error messages for users. By
>>>> using the dependency system, in combination with clustering or load
>>>> balancing, the user experience is always smooth and we avoid errors and
>>>> broken transactions and that sort of thing.
>>>>
>>>> On 04/20/2011 05:55 PM, Jim Tyrrell wrote:
>>>>> Should like in web traffic routing for clustering their be a stopped
>>>>> stage:
>>>>> add - adds
>>>>> remove - kills it
>>>>> enable - means it can accept new connections
>>>>> disable - mean no new requests
>>>>> stopped - means no request at all
>>>>>
>>>>> Jim Tyrrell
>>>>> Senior JBoss Solutions Architect
>>>>>
>>>>> Did you see RHT on CNBC's Mad Money?
>>>>> http://www.cnbc.com/id/39401056
>>>>>
>>>>>
>>>>>
>>>>> On Apr 20, 2011, at 8:31 AM, Stefano Maestri wrote:
>>>>>
>>>>>> When John have changed datasources subsystem he have created 4
>>>>>> operations for them:
>>>>>> - add
>>>>>> - remove
>>>>>> - enable
>>>>>> - disable
>>>>>>
>>>>>> I like them, now Heiko is asking to move enable/disable out in favour of
>>>>>> a more standard r/w attribute enabled (note that this attribute is
>>>>>> present in our xml). See There:
>>>>>>
>>>>>> https://issues.jboss.org/browse/JBAS-9341
>>>>>>
>>>>>> Since the operation don't just change the attribute, but also stop
>>>>>> services and unbind ds from jndi I'd prefer to keep operations as is. I
>>>>>> think an explicit operation make clearer to users that they are changing
>>>>>> the status of the entire datasourrce
>>>>>>
>>>>>> opinions?
>>>>>>
>>>>>> S.
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at lists.jboss.org<mailto:jboss-as7-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org<mailto:jboss-as7-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org<mailto:jboss-as7-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat



More information about the jboss-as7-dev mailing list