Okay, I'm going to post this here so that I can clear this up once and for all, because I keep answering the same questions over and over again regarding the system information tables and queries:

1) Any queries on the ServerSession* system information tables need to acquire a lock on each session in order to grab information about that session without the session itself modifying the information while it's being queried.

2) If a session is busy executing a request, particularly a long request, then it this query will have to wait until it can acquire the session lock.

This is an architectural issue, so while I *know* that it isn't ideal, I can't just "fix it" and release a new update.  So, until I can get this straightened out, it's *not* a good idea to constantly query these tables, especially in a production system where there may be long requests executing.  It's just going to end badly every time.  However, in general it is a good idea to make sure that you keep server requests as short as possible.  Long requests typically represent completely or significantly un-optimized queries, which don't belong in a production system.

After EWB 3 is released, I will be revisiting a lot of this architecture and seeing what I can do.  It may have to wait until EDB 3, but it may also be fixable without waiting that long.  The main issue is that these system information queries reach deep into the session for internal structures that are constantly being updated, so whatever I do will probably end up needing to copy this information out into a query-able storage location, and that adds overhead to every row lock, table lock, etc.  So, it's a balancing act...

Tim Young
Elevate Software
www.elevatesoft.com

Some additional information that I sent to Fernando today on this issue:

------------------------------------

Fernando asked about getting #506 errors on the client with only one session connected:

"I'm running a new test just now, but it will take some time because it's a "INSERT INTO <Table> SELECT ..." with about 500k rows.  It runs under a restrict transaction and there are no other concurrent sessions connected."

My reply:

"It's probably a situation where the client times out, disconnects, and then any re-connect attempts fail because the request is still being executed.  The EDB Server *does* check for this and will stop the request if it can detect that the connection has been dropped on the client side.   However, it is not always possible for the EDB Server to get a reliable indication that the connection has been dropped, due to switches, routers, etc.   In such a situation, the only reliable way to get the EDB Server to detect the dropped client connection is to enable progress updates for the TEDBQuery by attaching an OnProgress event handler.  That will make the EDB Server try to send a periodic response to the client, and this send operation will finally detect the dropped connection and stop the request."

------------------------------------

Another option is to just increase the timeout for the remote session on the client, or handle the TEDBSession OnRemoteTimeout event to allow the application to prompt the user regarding waiting for a response, etc.

More information:

https://www.elevatesoft.com/articles?action=view&category=edb&article=connections_disconnections_reconnections

Tim Young
Elevate Software
www.elevatesoft.com

I just want to let everyone know that I have already tested the solution proposed by Tim and so far so good:
Attaching an OnProgress event handler to the query when it takes a lot of time to complete seems to overcome this issue.

--
Fernando Dias
[Team Elevate]