conditional shutdown of the database

[Kathey Marsden <km...@sbcglobal.net>]

 I had asked on the user list if anyone had any ideas about how  a user
could conditionally shutdown a database, so that the shutdown would only
occur if there were no active connections to the database.  I could not
think of any way for the user to do this so am thinking of possibilities
for a solution on the development side.

My thought is that we could allow a different value  for the shutdown
attribute.

shutdown=ifInactive  ( or better name)

and for the embedded DataSources, add
setShutdown("ifInactive")

Does this seem like a reasonable enhancement?  I haven't researched it
really, but thought I would first see if there were objections.

Thanks

Kathey

Re: conditional shutdown of the database

[Mike Matrigali <mi...@sbcglobal.net>]

I don't think the transaction table is much help here.  It is a snap
shot, there is nothing to prevent a transaction from appearing 
immediately after the select returned. In I believe the VTI copies
the data when building the table, so a new transaction could come
about even before the user was finished "next'ing" through the result
set.

Daniel John Debrunner wrote:
> Kathey Marsden wrote:
> 
> 
>> I had asked on the user list if anyone had any ideas about how  a user
>>could conditionally shutdown a database, so that the shutdown would only
>>occur if there were no active connections to the database.  I could not
>>think of any way for the user to do this so am thinking of possibilities
>>for a solution on the development side.
>>
>>My thought is that we could allow a different value  for the shutdown
>>attribute.
>>
>>shutdown=ifInactive  ( or better name)
>>
>>and for the embedded DataSources, add
>>setShutdown("ifInactive")
>>
>>Does this seem like a reasonable enhancement?  I haven't researched it
>>really, but thought I would first see if there were objections.
> 
> 
> What's the definition of inactive? No other connections, no other
> transactions active? If it was no transactions then wouldn't a select
> from the transaction table returning no rows almost fulfill the same
> purpose?
> 
> I've often thought that a auto-shutdown based upon lack of activity
> would be a good thing, it would help to be tied in with auto-matic
> checkpointing/data flushing, maybe along the lines of what Raymond is
> thinking.
> 
> Dan.
> 
> 
> 
> 

Re: conditional shutdown of the database

[Kathey Marsden <km...@sbcglobal.net>]

Bryan Pendleton wrote:

>> No their issue is that the database remains booted after the connection
>> is closed.  They want to be able to shut it down after the test
>> connection iff there are no connections to the database.
>
>
> This seems like a nice feature to me.
>
> In other types of system software I've worked with, there is often the
> distinction between a "controlled" shutdown and an "immediate" shutdown,
> where the former means "finish up what you're doing now, but don't
> start anything new, then shut down", and the latter means
> "Shut.Down.Now."
>
> I even think that we should consider modifying the current shutdown
> command to mean "controlled" shutdown, and add a new command ("Halt"?
> "Abort"? "Quit"?) which is used to invoke the hard shutdown.
>
I'm not comfortable  changing  the current shutdown in that way at least
for embedded (which is what is at issue here).  Applications may be
depending on shutdown doing just that, even  if there are idle
connections hanging around.     I do think having a controlled
shutdown   is a good way to approach this and then we can throw a
different exception if the shutdown was not immediately successful.   
For this user, they would like "shutdown =controlled" to mean
    -  Continue to allow new connections. Wait until all connections
disconnect. shutdown when there are no connections.

But I could see folks might want.more granularity of control, for
instance they might want to control whether the server will accept new
connections or not or might just want to wait until current transactions
complete.

Kathey

Re: conditional shutdown of the database

[Bryan Pendleton <bp...@amberpoint.com>]

> No their issue is that the database remains booted after the connection
> is closed.  They want to be able to shut it down after the test
> connection iff there are no connections to the database.

This seems like a nice feature to me.

In other types of system software I've worked with, there is often the
distinction between a "controlled" shutdown and an "immediate" shutdown,
where the former means "finish up what you're doing now, but don't
start anything new, then shut down", and the latter means "Shut.Down.Now."

I even think that we should consider modifying the current shutdown
command to mean "controlled" shutdown, and add a new command ("Halt"?
"Abort"? "Quit"?) which is used to invoke the hard shutdown.

thanks,

bryan

Re: conditional shutdown of the database

[Kathey Marsden <km...@sbcglobal.net>]

Daniel John Debrunner wrote:

>Kathey Marsden wrote:
>
>  
>
>>Daniel John Debrunner wrote:
>>
>>
>>    
>>
>>>What's the definition of inactive? No other connections, no other
>>>transactions active?
>>>
>>>      
>>>
>>In this case, no other connections.
>>    
>>
>
>Hmm, I thought you had said they had some issue because the application
>had opened a test connection and never closed it. Maybe I misunderstood.
>
>  
>
No their issue is that the database remains booted after the connection
is closed.  They want to be able to shut it down after the test
connection iff there are no connections to the database.

Here is the original text from the user:

We have run into an issue  where a simple test connection that customers
are used to will cause the database to be useless unless the   NODE is
rebooted.  When configuring Failover, there was one option to do a
stand-alone where if the fist  node fails the second will take on,
Customers typically would test the connection on each of the nodes which
point to the same database.  This is failing today because after the
first test, and even though the connection is closed, the database can't
be accessed by the second node (JVM).  The test connection GUI can't do
a shutdown since some other customers use it sometimes while
applications are running and shutting the database then will result in
breaking those APPS.

Kathey

Re: conditional shutdown of the database

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

> Daniel John Debrunner wrote:
> 
> 
>>What's the definition of inactive? No other connections, no other
>>transactions active?
>>
> 
> In this case, no other connections.

Hmm, I thought you had said they had some issue because the application
had opened a test connection and never closed it. Maybe I misunderstood.

Dan.

Re: conditional shutdown of the database

[Kathey Marsden <km...@sbcglobal.net>]

Daniel John Debrunner wrote:

>What's the definition of inactive? No other connections, no other
>transactions active?
>
In this case, no other connections.

>I've often thought that a auto-shutdown based upon lack of activity
>would be a good thing, it would help to be tied in with auto-matic
>checkpointing/data flushing, maybe along the lines of what Raymond is
>thinking.
>
>  
>
Some sort of auto-shutdown would be great, but in this case it needs to
be quick.
The user would do  a connection test from one node and then the other. 
The original request was actually  for a property  to make the  database
shutdown  automatic if there were no connections.

Kathey

Re: conditional shutdown of the database

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

>  I had asked on the user list if anyone had any ideas about how  a user
> could conditionally shutdown a database, so that the shutdown would only
> occur if there were no active connections to the database.  I could not
> think of any way for the user to do this so am thinking of possibilities
> for a solution on the development side.
> 
> My thought is that we could allow a different value  for the shutdown
> attribute.
> 
> shutdown=ifInactive  ( or better name)
> 
> and for the embedded DataSources, add
> setShutdown("ifInactive")
> 
> Does this seem like a reasonable enhancement?  I haven't researched it
> really, but thought I would first see if there were objections.

What's the definition of inactive? No other connections, no other
transactions active? If it was no transactions then wouldn't a select
from the transaction table returning no rows almost fulfill the same
purpose?

I've often thought that a auto-shutdown based upon lack of activity
would be a good thing, it would help to be tied in with auto-matic
checkpointing/data flushing, maybe along the lines of what Raymond is
thinking.

Dan.