Ideal

>>> Essentially it is our own implementation of a parallel library where
>>> we control thread creation in such a way that initiates a session
>>> with each new thread that is created.
>
>> That is, indeed, a thread pool. You have done what I've been saying is
>> what you need to do. It is a proper architecture for this sort of
>
>No. Not at all. What I've created is a job system with persistent threads.
>
>You are missing the key differentiation.

Probably because we don't understand it. Can you explain or point to a URL that does?

Roy

<< Elevate DB's threading model is fundamentally flawed (or perhaps
antiquated) and is inherently incompatible to XE7's parallel library. >>

ElevateDB doesn't have a "threading model", at least not for the clients.
There are zero threads being used in an EDB client.

What ElevateDB *does* require is session isolation, and it needs this
because it has a *lot* state to maintain for given session (active
databases, cursors).  Traditionally, the situations that require concurrent
access to the same client session are so miniscule that it didn't warrant
addressing, and these requirements are not out of line when compared to
other data access technologies, which all require a separate connection per
thread (see my other reply about this).

Tim Young
Elevate Software
www.elevatesoft.com

<< The limitation in Elevate is that the one connection must stay with the
thread that created it.  That makes connection pooling essentially
impossible. >>

This is absolutely false.  ElevateDB has no problems with using session
pools for sessions.  The only stipulation is that you *do not* allow
concurrent access to the same session from multiple threads.

Tim Young
Elevate Software
www.elevatesoft.com

<< I am quite right.  Should you not maintain the rule of using a session
only in the thread that created it, your code becomes riddled with Error 506
from Elevate.  The rule as espoused by Tim in answer to the problem...
every session must only be used by the thread that created it.  An
unworkable solution for parallelism and pooling. >>

Please show me where I said that this is the solution to a #506 error.
#506 errors occur when you try to access the same client or server session
concurrently from multiple threads, so if you're seeing #506 errors, then
you're not doing something correctly with your pooling.

Tim Young
Elevate Software
www.elevatesoft.com

<< Tim himself has said that 506 can occur when you use a session from a
different thread than has created it. >>

Again, copies of these conversations where I said this would be nice.  I
checked to see if any support sessions were logged for Ideal in the past 2
years since implemented the new support sessions/logging, and we've had
zero.  I then checked to see if you've asked about this in the support
forums, and again, nothing.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< The limitation in Elevate is that the one connection must stay with the
>thread that created it. That makes connection pooling essentially
>impossible. >>
>
>This is absolutely false. ElevateDB has no problems with using session
>pools for sessions. The only stipulation is that you *do not* allow
>concurrent access to the same session from multiple threads.

One thing I wondered was do you need to give a session a bit of time to clean its act up after its been used in one thread and before you use it in another?

Roy Lambert

Roy,

<< One thing I wondered was do you need to give a session a bit of time to
clean its act up after its been used in one thread and before you use it in
another? >>

Not on the client.  As long as the client session is disconnected, then it
can be re-used.

And, the only way to get a #506 with a server session (the counterpart to
the client session that resides on the EDB Server) is if you tried to do
something with the server session (via the client session) while it was
still in the middle of trying to complete a request.  IOW, if you tried to
re-use an existing client session that was not disconnected.

Tim Young
Elevate Software
www.elevatesoft.com

<< The limitation in Elevate is that the one connection must stay with the
thread that created it.  That makes connection pooling essentially
impossible. >>

> This is absolutely false.  ElevateDB has no problems with using session
> pools for sessions.  The only stipulation is that you *do not* allow
> concurrent access to the same session from multiple threads.

Unfortunately, that has not proven itself out in practice.

> Please show me where I said that this is the solution to a #506 error.
> #506 errors occur when you try to access the same client or server session
> concurrently from multiple threads, so if you're seeing #506 errors, then
> you're not doing something correctly with your pooling.

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.

> 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.  

It's the connection to a database that can kill scalability.  The whole point is to share that connection across multiple threads (of course only one is in use by one thread at a time).