Ideal Software Systems wrote:

> MySQL, Firebird and Postgres are all free (as is MSSQL Express).
> Each of those allow connections to be pooled and used from threads
> that did not create the connections so long as it is in use by one
> thread at a time.  My expectations are that something that costs
> significantly more than free would be at least as functional.

So are you connecting to ElevateDB using the connections, or using the
direct to file option (which isn't provided by those you name)?

This is a basic architecture thing, as I have said before. COnnection
pooling is possible, because you can have a thread which takes requests
and services them using its connection (or session). I suspect, but
don't know because I've never needed to find out, that the Elevate
session might actually be sharable so long as only one thread is using
it at a time. I'd want to look for "threadvar" in the source to check.

But a network connection to a server is not comparable directly to the
Elevate session, and it is quite feasible for a well designed system.
Sure, it doesn't scale nicely to the automatic threading of the new
library, but in my opinion direct database access wouldn't be a good
way to implement such - you'd want a cache backed by a pool of threads
with their permanent connections.

Anyway, I think we are in agreement that the parallel library isn't
going to give you what you want the way you want with ElevateDB without
further work.

--

Matthew Jones

>I can't find error 506 in the manual - what is it?

ElevateDB Error #506 Cannot lock the session manager


> Interesting example, and it explains why so many web pages I visit are so slow.

My example was not a web example.  I was talking straight up desktop gui.

> So are you connecting to ElevateDB using the connections, or using the
> direct to file option (which isn't provided by those you name)?

We only ever allow connection through the server in order to minimize data corruption.

> and services them using its connection (or session). I suspect, but
> don't know because I've never needed to find out, that the Elevate
> session might actually be sharable so long as only one thread is using
> it at a time. I'd want to look for "threadvar" in the source to check.

Trust me, it's not sharable.  And that is the crux of the issue.

> library, but in my opinion direct database access wouldn't be a good
> way to implement such - you'd want a cache backed by a pool of threads
> with their permanent connections.

I do want that.  Elevate doesn't permit it unless you have some way to guarantee that the thread creating the connection / session will always be the only one to use it.  

Ideal Software Systems wrote:

> you'd want a cache backed by a pool of threads
> > with their permanent connections.
>
> I do want that.  Elevate doesn't permit it unless you have some way
> to guarantee that the thread creating the connection / session will
> always be the only one to use it.

The thread pool is the usual way to do this. For high activity tasks,
it is worth doing properly.

--

Matthew Jones

Ideal

>>I can't find error 506 in the manual - what is it?
>
>ElevateDB Error #506 Cannot lock the session manager

Thanks. Googling  I found an interesting thread about it

http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_sql&page=4&msg=4744

>> Interesting example, and it explains why so many web pages I visit are so slow.
>
>My example was not a web example. I was talking straight up desktop gui.

Definitely a good idea to populate on dropdown then.

Roy

Ideal


>Trust me, it's not sharable. And that is the crux of the issue.

Are we using the word sharing in different ways? If you want to have several threads using a session simultaneously that definitely won't work. Do you have a testbed we can play with?

Roy Lambert

> The thread pool is the usual way to do this. For high activity tasks,
> it is worth doing properly.

Exactly.  And you can't use a thread pool effectively with Elevate

>>Trust me, it's not sharable. And that is the crux of the issue.

>Are we using the word sharing in different ways? If you want to have several threads using a session >simultaneously that definitely won't work. Do you have a testbed we can play with?

Create three sessions in the main thread.  Create three threads that acquire and release those sessions such that only one thread can use a session at a time (basic connection pooling).  Throw any non-trivial amount of random load on those threads so that they are flipping between sessions, still using only one at a time but not always the same session.  You will start to see error 506.

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

We've proved that out in our application and can only get around it through developing our own deterministic job system.  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 thread's sole purpose is to look for jobs that have been submitted to it to do and then execute it within the context of the session.  It works very well and eliminates the error 506, but it requires then that you do all threaded work within the concept of a job, eliminates use of anonymous threads and has a fairly large memory footprint (since you can't spin up and down threads dynamically without causing database connection thrashing).

Ideal


>Create three sessions in the main thread. Create three threads that acquire and release those sessions such that only one thread can use a session at a time (basic connection pooling). Throw any non-trivial amount of random load on those threads so that they are flipping between sessions, still using only one at a time but not always the same session. You will start to see error 506.

I'm still very confused here. You seem to be specifying a 1:1 relationship between sessions & threads so why not create the three threads, have each of those create their own session in the constructor and just call the threads with their embedded session?

Roy

Ideal Software Systems wrote:

> 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
situation where you have a persistent connection that has a high
setup/break-down cost. It can be quite efficient too if you use the
right sort of queue management architecture so that adding a job
immediately triggers a waiting thread to start on it.

--

Matthew Jones