[jboss-as7-dev] DataSource Enable/disable

Tue Apr 26 02:54:57 EDT 2011

How about a state in which we only accept internal requests?

The problem that needs to be solved is the EJB (/Component) that starts 
to query a DS (or other EJB) after the shutdown request has been posted.

Carlo

On 04/21/2011 03:08 PM, 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
>