Ideal

>> Not on the client. As long as the client session is disconnected, then it
>> can be re-used.
>
>That is exactly the problem. Proper pooling does not require disconnection.

Unless I totally misunderstand what you're saying here it translates to "proper pooling does not require isolation" Hmmm. ALL of Delphi's threading requires controlled access to shared variables in threads.

Roy Lambert

<< Unfortunately, that has not proven itself out in practice. >>

I've attached session pool code for use with EDB.  I tested it with the
latest 2.18 and it works fine.  Because it handles exceptions properly and
resets the connection, it will keep on chugging along even if you stop the
EDB Server from listening for requests.  After you start the EDB Server back
up again, it will simply resume where it left off.

It uses a pool of 20 sessions, but hits it with 200 threads, so the pool
will increase to 200 sessions right away.  Of course, this is just a test,
so it doesn't shrink the pool, but if you need that code, let me know.

It will work with D7 or higher, in case you're using an older Delphi
version.

Tim Young
Elevate Software
www.elevatesoft.com

<< We understood that to be the case based on a response you gave here in
the forums.  If you'd like me to try to find the thread, I can do so. >>

This is why you should contact us directly if you have any questions, or if
something is unclear.  I would have immediately told you what the EDB design
actually is, and if there were issues with your code we could have resolved
them together.  There could have been a bug in EDB also, that has since been
fixed.  I couldn't find any log of such a bug in the incident reports, so I
doubt it.  But, it's hard to say for sure because we're talking about
everything after-the-fact.

In this case, you just assumed that EDB was broken and proceeded on your
way.  I have no idea what you were seeing, but it sure sounds like the pool
wasn't coded correctly.  EDB uses a mixed model (navigational/SQL), so it
has to maintain a lot more state per session than other database clients
that just pump SQL down the wire in a stateless manner.  So, it may have
just been a case of incorrect assumptions about how the pool could/should be
coded.

Tim Young
Elevate Software
www.elevatesoft.com

<< That is exactly the problem. Proper pooling does not require
disconnection. >>

My apologies - I was answering the question that I wanted Roy to ask,
instead of the question that he actually asked.  For normal connections
without any exceptions, yes, you can keep the session connected.  However,
if the session experiences a connection timeout exception, then you need to
make sure to disconnect the session.  Failure to do so will result in the
same session on the server being used (EDB automatically tries to
re-establish connections to existing server sessions, if it can) and will
result in a #506 error because the cause of the original client timeout (a
long running server request) will result in the client session trying to
connect to a session that is still busy executing the request, and
subsequently, is still locked.

The code that I posted just punts and resets the connection whenever there
is *any* exception, but you can get more fine-grained, if you want, by
dealing with specific error codes.

Tim Young
Elevate Software
www.elevatesoft.com

<< We understood that to be the case based on a response you gave here in
the forums.  If you'd like me to try to find the thread, I can do so. >>

> This is why you should contact us directly if you have any questions, or if
> something is unclear.  I would have immediately told you what the EDB design

We can certainly contact you with every question we have, but then what is the point of the forum?

> The code that I posted just punts and resets the connection whenever there
> is *any* exception, but you can get more fine-grained, if you want, by
> dealing with specific error codes.

Thanks for the pooling code. We'll investigate and see if it works for our setup.

> I've attached session pool code for use with EDB.  

Is there any way to do the error checking in the session component itself (or via a session event) so that it handles the reset rather than having to worry about resetting everywhere the exception may bubble up?

Ideal Software Systems wrote:

> but then what is the point of the forum?

Tim has made clear (see postings in every forum I think and the blog,
and emails) that the forums are primarily for peer support. It is a
good place for people to ask "am I doing something wrong here" type
questions, or "what is the best approach". But often we will say "raise
this direct with Tim" as he is the one who can give definitive
responses to some of the detailed operations.

And it is also worth saying that the quality of the responses is always
high, which is why I'm happy to pay for the maintenance on the products
that I depend on. I had a complex multi-threading issue once, and Tim
asked for the source. He cut it down to the minimum so it didn't need
my components, said he couldn't repeat it, I pointed out the line he'd
commented out that was key, he put it back, found the issue, released
an update. All within just a few days of me finding the problem. None
of this "we've added it to the queue, but need a three line example of
how to repeat it".

The forum is good for sharing with other users. Support is good for the
detailed responses one requires sometimes.

--

Matthew Jones

<< We can certainly contact you with every question we have, but then what
is the point of the forum? >>

I meant in a case similar to this one: if you expect something to work and
it doesn't, and it's important part of your application design.  In such a
case, you should definitely contact us directly to confirm whether what
you're seeing is by-design, a bug, or something else.  It will save you a
lot of time and trouble.

Tim Young
Elevate Software
www.elevatesoft.com

<< Is there any way to do the error checking in the session component itself
(or via a session event) so that it handles the reset rather than having to
worry about resetting everywhere the exception may bubble up? >>

I would really need to know more about exactly what operations you're trying
to execute to answer this in more detail, so this would probably be better
handled in a support session.  There are a lot of wrinkles involved with how
to handle things when the connection starts to go south due to timeouts,
etc, especially because EDB will try to do automatic reconnects on a
disconnected (as opposed to closed from a VCL component standpoint) session.

Tim Young
Elevate Software
www.elevatesoft.com