[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modules
Subject:    Re: [apache-modules] Apache 1.3 and db connection pooling
From:       Charles Reitzel <creitzel () rcn ! com>
Date:       2003-02-20 5:18:45
[Download RAW message or body]

Boy, I think HTTP is not a good choice of protocol for such large data 
transfers.  Why not use FTP (which has much better error recovery, is 
restartable) to transfer the whole thing and kick off a batch 
job?  Old-fashioned, yes, but better suited to the task.  No need to 
involve a web server at all.

As you probably know, with a transaction of that size, you'll want to tune 
your Oracle rollback segments.

At 07:43 PM 2/19/2003 +0000, Kyrre Kristiansen wrote:

>Well, that's a part of the problem. We're not in
>HTML-country at the moment. The appliction is using a
>custom protocol over HTTP, so we have no notion of
>forms or other HTML constructs.
>
>The data is going to be quite big, at least 10Mb,
>possibly 10-100 times that, so we're going to "stream"
>parts of the data, send that, and while things are
>happening on the server, we can "stream" another part,
>so that when we get a response, we can just send the
>next bit, and so on. The reason we need to keep track
>of the database connection, is that if something goes
>wrong in request 2 of 5, say, we can rollback
>everything that was sent before, as well as the
>current data.
>
>
> > >Is there a way of either:
> > >1. Make sure that each request from a client uses the
> > >same Apache  process, and make that hold the actual
> > >connection in-between requests.
> > >
> > >2. Make a global connection-pool, and make sure that
> > >all the sub-processes have access to the same pool,
> > >including synchronisation.

There are no SQL client libraries written to run using purely shared 
memory.  Thus, there is no such thing as a cross-process connection pool.

Although there is no existing mechanism to route all requests for a session 
to a particular worker process, 1) is the more workable of the two 
ideas.  For example, there are routers that can route all session activity 
to a particular web server, however, and this is called "session 
affinity".   Java app servers, well WebSphere anyway, will attempt to route 
all session traffic to a particular JVM.  But this is not guaranteed, only 
a "best effort".

But, for your application, better to avoid the whole thing.

take it easy,
Charlie



---------------------------------------------------------------------
To unsubscribe, e-mail: apache-modules-unsubscribe@covalent.net
For additional commands, e-mail: apache-modules-help@covalent.net

[prev in list] [next in list] [prev in thread] [next in thread]