On 2008.04.16, Tom Jackson [EMAIL PROTECTED] wrote:
Connections are persistent, but sessions are not. [ns_db releasehandle]!
In most databases, a session is defined as a connection's lifetime.
When you release the nsdb handle back to the pool, it doesn't actually
terminate the session and/or
On Wed, Apr 16, 2008 at 09:26:09PM -0700, Tom Jackson wrote:
If something actually gets complex, it is probably better done in the pl
language, which can end up being several orders of magnitude faster.
Or it can end up being enormously slower. It Depends. I've seen both
happen with Oracle
On Wed, Apr 16, 2008 at 08:19:23PM -0700, Jade Rubick wrote:
Can someone explain why we need prepared statements?
With Oracle (and nsoracle), basically you don't.
I thought by using bind variables, we avoid the SQL parse time (at
least with Oracle, that's my understanding) if you're using the
On Wed, Apr 16, 2008 at 10:00:14PM -0400, Dossy Shiobara wrote:
On 2008.04.17, Bas Scheffers [EMAIL PROTECTED] wrote:
That brings me to another subject: do we want prepared statements?
Yes!
No. Or perhaps it's more accurate to say, no, hardly ever, but
perhaps on very rare occasions.
On 2008.04.17, Andrew Piskorski [EMAIL PROTECTED] wrote:
to know this)--so, caching/reuse of prepared statements really should
be left up to the application code, as the developer ought to know when
it can be reused vs. when it should be flushed/re-prepared.
Yuck. IMO, the application
On Thursday 17 April 2008 05:50, Dossy Shiobara wrote:
Yuck. IMO, the application developer MIGHT on occasion want that
level of control available, but forcing him to use it for every single
database access is sub-standard API design.
I never suggested that prepared statements _replace_
it, NOT ignore it and roll your own emulation of
bind variables in higher level code. This means that the various ns*
database drivers MUST be involved in proper AOLserver bind variable
support. Now, ns_db certainly can and should provide the various
calls, which hook into the driver-specific code
On Wednesday 16 April 2008 17:06, Andrew Piskorski wrote:
As a design principle, remember that ns_db itself never cares what is
in the query at all! ns_db doesn't even care whether the query is
SQL or something else, the query is just some opaque string which gets
passed allong to the proper
+1
- Original Message
From: Dossy Shiobara [EMAIL PROTECTED]
To: AOLSERVER@LISTSERV.AOL.COM
Sent: Wednesday, April 16, 2008 7:00:14 PM
Subject: Re: [AOLSERVER] ns_db and bind variable support
On 2008.04.17, Bas Scheffers [EMAIL PROTECTED] wrote:
That brings me to another subject: do we
On 2008.04.16, Jade Rubick [EMAIL PROTECTED] wrote:
Can someone explain why we need prepared statements? I thought by
using bind variables, we avoid the SQL parse time (at least with
Oracle, that's my understanding) if you're using the same SQL but with
different values in your bind variables.
On Apr 16, 2008, at 8:48 PM, Jeff Rogers wrote:
I've been told this by every oracle dba I've worked with and the
performance gains I've seen by moving to prepared statements is
generally quite small unless the sql is horrendously complex, and
even then the backends appear to do caching of
On 2008.04.16, Don Baccus [EMAIL PROTECTED] wrote:
Did you try speeding up the plan generation using Oracle's method of
giving hints?
Yes, we /*+HINTED*/. Oracle trace log showed parse times of 160ms +/-
10ms. Plan generation wasn't the killer. Parsing the SQL was the
killer. It wasn't
I haven't seen any discussion here which approximates how current SQL
standards handle prepared statements. Actual prepared statements would be of
little benefit in AOLserver since the lifetime of an SQL session is so short,
there is very little opportunity for reuse. Prepared statements are
On 2008.04.16, Tom Jackson [EMAIL PROTECTED] wrote:
Actual prepared statements would be of little benefit in AOLserver
since the lifetime of an SQL session is so short, [...]
Huh? AOLserver offers pooled, persistent database connections.
--
Dossy Shiobara | [EMAIL PROTECTED] |
14 matches
Mail list logo
