db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: Methods for upgrading database and application
Date Fri, 15 Feb 2008 13:04:37 GMT
Brad Moore wrote:

> I am thinking that when JMX support is implemented that I will use that 
> feature, but in the meantime I think I will create a table that tracks 
> which user has logged in and the date and time that they logged in, as 
> well as when they have logged out.  When I need to perform a database 
> upgrade I will query the table and see if there are any users that have 
> logged in but have not yet logged out.  I will raise a warning message 
> telling the user that is performing the upgrade that there may be users 
> currently logged into the database and list the names of the users that 
> are currently showing as logged in.  I will let the user choose to 
> continue the upgrade if they have determined that none of those users 
> are actually logged in any more.  I will have to allow them to continue 
> anyways because there may be cases where someone logs into the system 
> which would create the "logged in" record but they shut their computer 
> down without logging out, or they logged into the system and then left 
> their computer turned on and went home for the weekend.

I was going to suggest checking for the existense of the db.lck file in the 
database directory (which should be there iff the database is booted), but I 
don't think that would be more reliable than your current plan.

> I will then set a flag in the database that disallows anyone from 
> connecting to it during the upgrade.  Is there a system property for 
> this?  And then reboot the database, which will kick everyone out of the 
> database.

I am not aware of such a property/setting. One other way of doing it may be to 
utilize some of Derby's security features (authentication, authorization) during 
upgrade. E.g. something like this:

1. shut down Derby (kicking out connected users)
2. define a single system-level user for upgrade, requiring authentication
3. reboot the driver/server and the database (for the new settings to take 
effect), perform the upgrade (other users will not be able to connect)
4. shut down Derby
5. restart the app...

> After performing the upgrade I will restore the flag that allows users 
> to connect to the database.
> If anyone has any better suggestions than this I am open to ideas.  JMX 
> does sound like a great solution but I don't have the time or knowledge 
> to roll my own right now and the Derby JMX support sounds like it is not 
> completed yet.  Maybe for a future release.

You are right, the Derby's JMX features are not yet part of any release, tough 
there will probably be a limited feature set available in the next release. It 
seems to me that the number of active sessions in the Network Server is a good 
candidate for what kind of information could/should be available through JMX - 
thanks for providing a good use case :)


View raw message