Raul,

>AFAIK EDB is fairly aggressive in removing dead Sessions so i doubt it's
the sessions.<

That of course is assuming someone hasn't changed the session timeout to a much larger number. (That is the problem when the settings are stored in a plain text file).

He should check the edbsrvr.ini file just in case.

I think these are the default settings:

Server Session Timeout=180
Sever Dead Session interval=30
Server Dead Session Expiration=300
Server Maximum Dead Sessions=64

Barry

Thanks Raul

>> AFAIK EDB is fairly aggressive in removing dead Sessions so i doubt it's
>> the sessions.

The problem is that I don't see how it can be anything else on that list apart from the sessions. I don't have access to the customer's machines but I guess could try to put some code in an update which reports in the contents of the "ServerSession" table in the error report.

Unless the mighty Tim has any other thoughts?

On 9/20/2013 4:01 AM, Hedley Muscroft wrote:
> The problem is that I don't see how it can be anything else on that list apart from the sessions. I don't have access to the customer's machines but I guess could try to put some code in an update which reports in the contents of the "ServerSession" table in the error report.

That list was a guess to start with - EDB internally has likely more
places where this could occur.

Does your customer have access to EDBManager? There is an option to
manage sessions there as well - as a quick test when error occurs to
check and see how many connections are there.

Also the edb server event log might shows something.


> Unless the mighty Tim has any other thoughts?
>
Let's hope Tim drops back in soon and takes a look

Raul

Hedley,

<< That customer is on 2.12 build 2 - as are dozens of other customers who
aren't experiencing any issues. >>

Yeah, 2.12 B2 should be fine.

<< This is the Client/Server version of EDB and my app is a C# .NET program
which uses the EDB ADO.NET drivers.

The routine which through this error in the last reported instance was
nothing special - just a SELECT statement which returned a handful of rows.
>>

I've got the same response as the others that have already responded - you
need to find out if you're actually exceeding the number of allowable
sessions on the EDB Server (4096), or are somehow "leaking" sessions.  You
can do this by looking at the EDB Server UI, or using a remote session to
query this table:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ServerSessions_Table

Tim Young
Elevate Software
www.elevatesoft.com

Hedley,

<< As I'm using ADO.NET with connection pooling enabled... I wonder if
there's something in the EDB ADO.NET implementation which might not be
closing connections correctly? >>

No.  ElevateDB doesn't have any issues with closing connections.

However, you could run into this issue when using connection pooling,
especially if the sessions are timing out on the EDB Server, becoming "dead"
sessions, and then not being removed promptly.  Querying the ServerSessions
table, as noted in my previous response, will tell you whether this is
occurring or not.

Are you enabling pinging (PING keyword) in your connection string for your
connections:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2dac&topic=NET_Connection_Strings

If not, then the pooled connections will *definitely* time out after a
while, and the EDB Server will not remove the associated session until the
configured dead session expiration time is hit (this allows for
re-connects).  However, the default maximum number of allowed dead sessions
is 64, so that will act as a limiting factor unless it has been modified.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim - I think I may have found the issue...

I actually implement my own layer of reference-counted EDBConnection caching in my application.

When I first started developing with EDB C/S, all my customers kept getting #300 Session Lock errors when connections were being used across multiple threads. The caching layer silently creates a new EDBConnection object if/when it hits a "#300 session lock" from a secondary (non-UI) thread and then disposes of the connections when not in use.

Anyway, I just found a bug in one place where the connection was not being de-referenced. It's hard to believe that this would end up hitting the 4096 limit, but I guess if the app is running for days, that could happen! :-/

My next update will fix that issue, so I'll let you know if it re-occurs.

Many thanks to everyone for their help!

Kind Regards,

Hedley

Hedley,

<< Anyway, I just found a bug in one place where the connection was not
being de-referenced. It's hard to believe that this would end up hitting the
4096 limit, but I guess if the app is running for days, that could happen!
:-/ >>

Yeah !  I love "not my bug"s.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com