Matthew

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

One thing I don't understand is why create the sessions in the main thread. Wouldn't it make more sense to create them in the treads themselves?

Roy

Roy Lambert 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.
>
> One thing I don't understand is why create the sessions in the main
> thread. Wouldn't it make more sense to create them in the treads
> themselves?

You would, yes. Not sure where I said anything about the main thread.
You have one or more threads that are doing "the work", and one or more
threads that do "database lookups". And to connect them, a queue of
jobs. The work thread creates a job, and then waits for a database
thread to return the response (which could be cached if appropriate).
The overhead can be very small if you use things like the Windows
synchronisation objects which a thread waits on, but I've not actually
needed that fast a system as my thread pools are doing internet client
work.

--

Matthew Jones

Matthew


>> One thing I don't understand is why create the sessions in the main
>> thread. Wouldn't it make more sense to create them in the treads
>> themselves?

>You would, yes. Not sure where I said anything about the main thread.
>You have one or more threads that are doing "the work", and one or more
>threads that do "database lookups". And to connect them, a queue of
>jobs. The work thread creates a job, and then waits for a database
>thread to return the response (which could be cached if appropriate).
>The overhead can be very small if you use things like the Windows
>synchronisation objects which a thread waits on, but I've not actually
>needed that fast a system as my thread pools are doing internet client
>work.

Apart from the fact that my stuff is local, or reading email/newsgroups not internet that sounds like the sort of thing I do. My question was prompted by Ideal posting <<Create three sessions in the main thread.>>

In some ways I'm lucky a) being a hobbyist and b) nothing I've done in the last 10 years or so is sufficiently time critical that I'm bothered about the expense of creating a session.

Roy

On 4/30/2015 5:55 AM, Roy Lambert wrote:
> One thing I don't understand is why create the sessions in the main thread. Wouldn't it make more sense to create them in the treads themselves?

The issue in using some of the new parallel functionality is around that
you don't go out and create the discrete threads the standard way in
most cases (even thread pooling often is completely transparent ot the
app - "work" just happens in parallel threads).

Session pooling where you create sessions up-front in main thread and
then hand them out as needed would be one way around this.

As has been said before it's an architectural aspect of EDB that at this
time does not cleanly fit into the new parallel library model.

IMHO nothing wrong with this for EDB v2 (it was never promised to be
supported) but we'll see if Tim sees any value in accommodating some of
this in EDBv3 in the future.

One issue i see is that the gains in parallel might not be what people
are hoping. We have implemented number of parallel aspects of processing
in our main app. In some cases there are definite benefits and in others
the processing is not the bottleneck (especially i find if DB or disk
get involved) or overhead limits gains.

Again this is app/scenario specific and for some cases there might be
valid gains to be had (i tend to see lot of parallel programming samples
use various math computations - those scale/distribute with almost no
overhead in many cases).

Raul

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

Because then a new connection is created when each thread is spun up and destroyed when each thread is finished.  A scalability nightmare.

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

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
>
> No.  Not at all.  What I've created is a job system with persistent
> threads.
>
> You are missing the key differentiation.

Hmm. I think this is just being picky, but we are here to help each
other, not fight over terms. Have a good weekend.

--

Matthew Jones

> One thing I don't understand is why create the sessions in the main thread. Wouldn't it make more sense to create them in the treads themselves?

One word... Scalability

Connections to a database server are costly.  That is why you usually spin up a bunch of connections and acquire them for use within a thread and release when the thread has finished it's work.

> > You are missing the key differentiation.

> Hmm. I think this is just being picky, but we are here to help each
> other, not fight over terms. Have a good weekend.

It's not being picky. They are two entirely different concepts.

Ideal

>>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?
>
>Because then a new connection is created when each thread is spun up and destroyed when each thread is finished. A scalability nightmare.

Confusion continues - you want to pool connections but you're not willing to pool threads?

Roy