Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Discuss: PreparedStatement and Connection Pooling

Reply
Thread Tools

Discuss: PreparedStatement and Connection Pooling

 
 
Raj
Guest
Posts: n/a
 
      08-25-2003
I've looked high and low for a satisfactory answer but could not find
one.

I've always thought PreparedStatements were more efficient than
Statements since they are precompiled. Then I read somewhere that if
the preparedstatements were being closed, the database will have to
recompile the preparedstatements again. Somebody tell me that this is
not true since the connections are only being returned to the
connection pool and not actually being closed, the precompiled
preparedstatement is still out there.

Or if I am wrong, please correct me.

Thanks,
Raj
 
Reply With Quote
 
 
 
 
Adam Maass
Guest
Posts: n/a
 
      08-25-2003

"Raj" <(E-Mail Removed)> wrote:
> I've looked high and low for a satisfactory answer but could not find
> one.
>
> I've always thought PreparedStatements were more efficient than
> Statements since they are precompiled. Then I read somewhere that if
> the preparedstatements were being closed, the database will have to
> recompile the preparedstatements again. Somebody tell me that this is
> not true since the connections are only being returned to the
> connection pool and not actually being closed, the precompiled
> preparedstatement is still out there.
>


Depends on the database and driver.

My understanding of Oracle is that *any* SQL text sent to it for execution
is first checked against a list of recently-executed SQL so that the
execution plans, if any, could be re-used. Some Oracle design books make a
big deal out of standardizing your SQL indentation style to increase the
chances of a match during this process. But of course, if your
PreparedStatement objects use the same SQL, then you will have matches after
the first one.

Of course, if you're using WebLogic connection pooling, there's an awful lot
that happens behind-the-scenes to avoid "premature" closing of database
resources. (IE, closing a PreparedStatement doesn't actually release
anything in the database except any open ResultSets -- and closing a
Connection simply returns it to the pool.)

Normally, I wouldn't worry about these kinds of things. There is one
advantage to PreparedStatement even if the driver does nothing more than
turn it into a regular plain-vanilla Statement behind your back: The
PreparedStatement contract handles string escape syntax for you. That is,
you don't have to worry about escaping strings with embedded apostrophes in
them; you let the driver do it for you.

-- Adam Maass


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ADO.NET, connection pooling and ASP.NET Rob Nicholson ASP .Net 18 09-17-2005 03:49 PM
Connection Pooling and the data access application block Edward W. ASP .Net 5 12-15-2004 04:41 AM
Tomcat and JDBC connection pooling Baba Java 3 02-23-2004 11:33 AM
WebLogic 6.1 execute threads and database connection pooling configuration Justin M Java 0 12-08-2003 08:26 PM
Re: SqlConnection and connection pooling William \(Bill\) Vaughn ASP .Net 0 11-14-2003 07:27 PM



Advertisments