Windows Server Remote Desktop Problem

dsf

I have a problem with remote desktop.
A user logs in and opens a particular program. If the user closes the connection with out closing the program then the program continues to run until the server kills the process. This causes an un-graceful shutdown of the application that locks what ever the user was doing in the database. The solution so far has been to go into the database and unlock everything manually. This event occurs too often to do this on a regular basis. I'm not sure even where to begin. I have googled, "how do I capture the remote desktop close event". But haven't gotten much good info yet.

Anyone have any suggestions?

George Patches

I suggest you change the properties of Remote Desktop so that a user session doesn't timeout.

dsf

rgr that, then can I change the program to time out and then on time out close properly?

George Patches

Well I'm operating under the assumption that the reason the server is killing your process is because it's killing the user session. If you stop it killing the user session it shouldn't kill your process any more.

dsf

The user session needs to be gracefully shut down because the user closed the session rather than closed the app then closed the session. It's a sloppy shut down that locks up the data base.

Apreche

Sounds to me like this is what might be happening:

In your app if someone clicks the close button or goes to File->Quit then you are executing the code to stop your database activity and close your database connection.

If someone clicks Start->Log Out on a modern Windows system, they don't actually close their session. They aren't supposed to. They are supposed to be able to switch user again and resume from where they left off. That even includes any processing. So I shoudl be able to login to a computer as Scott, start a video encoding, then switch user to Rym and play a game, then switch back to scott later and the video encode will be finished.

The real problems here are why is the database locked just because someone left the app open? Why does your app crash just because it is open for a long time? Neither of those things should happen ever regardless of any remote desktop or logging out.

A crappy duct tape solution is to do this. Every time the application needs to interact with the database it starts a new connection, does its work, then closes the connection. This way even if the app is running, it won't be connected to the database unless it is actively doing some task.

George Patches

If someone clicks Start->Log Out on a modern Windows system, they don't actually close their session. They aren't supposed to. They are supposed to be able to switch user again and resume from where they left off. That even includes any processing. So I shoudl be able to login to a computer as Scott, start a video encoding, then switch user to Rym and play a game, then switch back to scott later and the video encode will be finished.

Log off = end session
Switch user = lock current session an allow another session to also log in.

The real problems here are why is the database locked just because someone left the app open? Why does your app crash just because it is open for a long time? Neither of those things should happen ever regardless of any remote desktop or logging out.

It's not crashing. People are closed the RD session, which locks the session rather than log it out. However by default there's a 10 minute time out at which point windows will force close everything in that session and log it out. That's why his process is getting killed. If you allow sessions to persist then you can log back in and close it properly.

Apreche

I figured that logging off of a remote desktop was a little different because you would just be disconnecting network-wise, but you wouldn't want the session itself to close. You would want to log back in and still have everything as it was when you disconnected.

If that is not the case, then the problem might be simpler than that. Your app just needs to listen for the log off/shutdown event and when it sees that event, shut down safely.

dsf

it's a multi user app that locks sections that the user is viewing. The issue is that if someone doesn't close the app properly it will not release control of those sections. Thus, no one else can use it.

I figured that logging off of a remote desktop was a little different because you would just be disconnecting network-wise, but you wouldn't want the session itself to close. You would want to log back in and still have everything as it was when you disconnected.

If that is not the case, then the problem might be simpler than that. Your app just needs to listen for the log off/shutdown event and when it sees that event, shut down safely.

^ I think you are right about the session staying open incase you want to reconnect

My impression is that the session stays open for X seconds if you disconnect improperly and then the server kills the session after X seconds. This process kill doesn "shutdown" apps running in the session it just kills them meaning that don't run their shutdown processes to resolve what they are doing.

George Patches

^ I think you are right about the session staying open incase you want to reconnect

My impression is that the session stays open for X seconds if you disconnect improperly and then the server kills the session after X seconds. This process kill doesn "shutdown" apps running in the session it just kills them meaning that don't run their shutdown processes to resolve what they are doing.

Exactly, like I said the first time. Are you an admin on this machine?

dsf

yes

Apreche

it's a multi user app that locks sections that the user is viewing. The issue is that if someone doesn't close the app properly it will not release control of those sections. Thus, no one else can use it.

That is ridiculous. When you view a section it should query once and show you the data. You should not lock a table just because someone is looking at it. Let everyone see it at once.

I think you are trying to solve the problem of one user writing, then another user writing on old data blowing away the first user's changes. That problem is much better solved many other ways.

On way is to use something like couchdb, which is built to handle that exact situation.

With a relational Database, you probably want to do things Wordpress style. In WordPress when you write a blog post it actually has two tables. One table is for the posts and the other table is for revisions. When you create the post you get a row in each table, obviously with a foreign key from revision to post. Every time you edit the post, it inserts another row into the revision table. When you visit the blog, you always see the data from the newest active revision on the post. You never update any data in the db, you only ever insert new rows. This way no data is ever lost.

On top of that you want all of these inserts to be performed in transactions, so they are atomic and always happen in order. Then when someone submits a new revision they include the id of the previous revision. If the id they submit is not the id of the latest revision, send them back telling them that data has been changed while they were editing. Give them a screen showing them the newer data and the data they submitted allow them to reconcile and submit again. This doesn't work if you have a ton of people writing the same thing simultaneously, but that shouldn't be a problem.

Also, you might want to take a look at how Wikipedia handles this problem. They basically use typical diff/merge version control if multiple people edit the same wiki page simultaneously.

George Patches

yes

gpedit.msc
user configuration => admin templates => windows components => terminal services (Remote desktop if 2K8) => sessions

dsf

I understand what you are saying Scott, but I have no control over how the software works. It is an MS Word plugin and was written ages ago in VB 6 and barely functions as intended. It's essentially a multi-user document manager that allows people to keep live documents in it. When a user wants to manage a document they "take control" of it and lock it while they use it. In order for others to write to the document again they need to release control or properly shut off the application because this will release control automagically.
So when someone closes a remote desktop connection with the program running, it will continue to run because it thinks the user will come back at some point. After X amount of time, the server will terminate the remote desktop session and kill all programs running in it. This leaves the documents in a locked state that can only be unlocked if the user logs back on and unlocks them manually or someone who can access the database changes their locked status. Note: Even if the documents are locked, they can be read, just not written to.
I know this program sucks, but there is nothing I can do about it. My professor essentially is dumping his bitch work on me in the name of my independent study and holding my grade hostage so I can solve his problems.

But whatever, this problem is solvable I think.

dsf

Thanks for the help guys, I appreciate it.

Rym

Replace it with Sharepoint.

George Patches

Thanks for the help guys, I appreciate it.

Did the sessions mod I suggested help? Also, have you tried bludgeoning your users when they forget to close it properly?

dsf

Thanks for the help guys, I appreciate it.

Did the sessions mod I suggested help? Also, have you tried bludgeoning your users when they forget to close it properly?

The issue isn't closed yet, but I have a good start.