Re: php/apache/oracle

From: Ana C. Dent <anacedent_at_hotmail.com>
Date: Tue, 03 Jul 2007 02:25:59 GMT
Message-ID: <Xsiii.253437$Fk2.235008@newsfe08.phx>

Pauly <darakjia_at_gmail.com> wrote in
news:1183400218.300132.164860_at_e16g2000pri.googlegroups.com:

> Thanks Ana. Please, see my embedded comments ...
> On Jun 29, 7:20 pm, "Ana C. Dent" <anaced..._at_hotmail.com> wrote:

>> Pauly <darak..._at_gmail.com> wrote in news:1183151798.622697.18830
>> @x35g2000prf.googlegroups.com:
>>
>> > Would anybody have a good idea of the pros and cons of using php on
>> > an 
>>
>> as compared to what alternative

>
> As compared to Tomcat/Java/Oracle or IIS/C#/Oracle

A DayJob one group went with JBoss/Java about a year ago. Now they are working to replace JBOSS 'cuz it won't stay up.

>

>>
>> > Apache server to connect to and run queries on an Oracle database.
>> > The database concerns mostly with genetic data. Therefore, the
>> > queries can be pretty complex and time-consuming (millions of rows
>> > on large number of tables).
>>
>> One possible problem is network timeout while LONG running SQL to
>> return. 

>
> Yes, you are right. But in this case I am not sure I have control over
> it.
>

>>
>> How much data actually gets returned to browser?
>>

>
> Might be thousands of rows, in which case it will be dumped into a txt
> file instead of being displayed on the browser.

Anything under 10K rows is not a problem.

>

>> > I am also concerned about concurrent queries
>>
>> Don't worry about concurrent queries.
>>

>
> Why do you think I shouldn't be concerned with that?

Oracle was designed to support concurrent queries; so you don't have worry.
With Oracle Readers do not block Writers & Writers do not block Readers.

>

>> > and am
>> > inclined to implement connection pooling so that time can be saved
>> > on the creation of new connections to the db every time a query is
>> > fired. Anybody with experience on this? Thanks!
>>
>> One of my motto is "First make it work, then make it fancy.
>> IMO, hold off on connection pooling until everything else works AND
>> performance measurements indicate it is justified.
>>

>
> OK. I just thought that I should have these things figured out first
> so that
> I don't have to make significant changes in the future (maybe in this
> case the changes
> won't be significant).

You should have a single module/method for providing a working connection to the DB to a requesting thread. If designed properly replace the code that provides ad hoc connections with one that does connection pooling should be as simple a changing a tire. Received on Mon Jul 02 2007 - 21:25:59 CDT