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 :)


--
John

Reply via email to