When we have an app crash, it will lock out 80% of connection attempts from that point on until you restart the server.  The exception raised is:

Exception class EEDBException with message 'ElevateDB Error #300 Cannot lock the database XYZ for shared access'.

This is very easy to replicate by terminating the debugger while stepping through your app and then trying to start it up again immediately.

What causes this and what can be done to mitigate the problem?

Ideal

>When we have an app crash, it will lock out 80% of connection attempts from that point on until you restart the server. The exception raised is:
>
>Exception class EEDBException with message 'ElevateDB Error #300 Cannot lock the database XYZ for shared access'.
>
>This is very easy to replicate by terminating the debugger while stepping through your app and then trying to start it up again immediately.
>
>What causes this and what can be done to mitigate the problem?

Since you're running the server my guess would be that some connections are still there and are waiting for the timeout to be reached so the dead sessions are removed and its back to business as usual.

As far as the server is concerned then on the Sessions page of the server options you can set the values as low as practicable so that dead sessions get cleaned up as soon as possible.

Roy Lambert

Ideal Software Systems wrote:

>What causes this and what can be done to mitigate the problem?

This might help.

To see the connected sessions, from EDBMgr execute:
 select * from configuration.serversessions

and
 select * from configuration.serversessionlocks

Barry

It doesn't matter if you clear the sessions.

It also doesn't matter if you stop and restart the server.  The only way to free it up so that apps can reconnect is to exit the server process and then restart it.


Roy Lambert wrote:

Ideal

>When we have an app crash, it will lock out 80% of connection attempts from that point on until you restart the server. The exception raised is:
>
>Exception class EEDBException with message 'ElevateDB Error #300 Cannot lock the database XYZ for shared access'.
>
>This is very easy to replicate by terminating the debugger while stepping through your app and then trying to start it up again immediately.
>
>What causes this and what can be done to mitigate the problem?

Since you're running the server my guess would be that some connections are still there and are waiting for the timeout to be reached so the dead sessions are removed and its back to business as usual.

As far as the server is concerned then on the Sessions page of the server options you can set the values as low as practicable so that dead sessions get cleaned up as soon as possible.

Roy Lambert

There are no locks outside of the shared locks I always see.  Nothing is exclusive.

Barry wrote:

Ideal Software Systems wrote:

>What causes this and what can be done to mitigate the problem?

This might help.

To see the connected sessions, from EDBMgr execute:
 select * from configuration.serversessions

and
 select * from configuration.serversessionlocks

Barry

Ideal


If you have the c/s source code than try recompiling with something like MadExcept. That might give you a clue as to what's going on. Otherwise you're best approach would probably be to raise a support ticket with Tim.

Another question - do you know why your app is crashing?

Roy Lambert

The easiest way to reproduce it is to terminate the Delphi debugger while you are running the application.  I'm not sure that MadExcept would help us unless we know where the error is raised so we could manually  alert MadExcept. It's handled and passed down to the client so I doubt Mad Except would ever see it.

As to why it crashes in the wild, there are several different cases and we're addressing each as we find them.

Roy Lambert wrote:

Ideal


If you have the c/s source code than try recompiling with something like MadExcept. That might give you a clue as to what's going on. Otherwise you're best approach would probably be to raise a support ticket with Tim.

Another question - do you know why your app is crashing?

Roy Lambert

Ideal


Can you produce a test case for people to have a look at?



Roy Lambert

> When we have an app crash, it will lock out 80% of connection attempts
> from that point on until you restart the server.  The exception raised is:
> Exception class EEDBException with message 'ElevateDB Error #300 Cannot
> lock the database XYZ for shared access'.

Ran into this today with a client.  They had a workstation crash and that
was causing error #300 errors for subsequent connections from other
workstations.  The weird thing about ours was that the workstation that
crashed was the 3rd workstation to connect to the server.  After the crash,
we could get 2 clients in, but the 3rd would fail.

So it looks like there is a problem with file locks being left behind that
don't get cleared by the OS until the server engine is closed.

---------------------------------------
Terry Swiers
Millennium Software, Inc.
http://www.1000years.com
http://www.atrex.com
---------------------------------------

Terry
,
Maybe these links will help confirm that:

http://www.12qw.ch/2013/09/tooltips-unlocking-files-with-sysinternals-process-monitor/

https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Barry