> > My main point is that performance generally isn't that much an issue in
> > server side web development.
>
> I cant believe this !!! . In out project we are trying hard to increase
> throughput and response time/performance. These small-2 points add and
> later create problems.
>
> > e.g. the difference between using Connection pooling or not is in the
> order
> > of 100 - 300 ms. In that case, it does matter.
>
> Ok I agree
>
>
> > Security: I already said that it was my favorite trick to break into asp
> > sites (these generally don't use PreparedStatements. I don't
> know if such
> a
> > thing exists in asp)
> > image your login check as:
> > String userName = request.getParameter("userName");
> > String passWord = ....
> > ResultSet rs = stmt.executeQuery("select userName, status from
> login where
> > userName = '"+userName+"' and password = '"+password+"'");
> >
> > Now, I can login by using userName/password
> > test / test' or '1'='1
> >
> > Believe me. It works. I've seen them doing it, man ;-)
>
> I am not including such poorly developed site.
>
I didn't say that. But many developers do. So, I'm correct in saying that
the PreparedStatement should be the default ;-)
The article about the speed difference is about a specific DBMS and a
specific Driver. I doubt that you would see the same results in another
setup. So, unless you did proper profiling, you should never give up on
clean code, security, .. in favor of 'supposed' performance.
If you did proper tuning, go ahead and use a Statement for performance's
sake, but the default is still Prepared.
BTW, I could easily create an ODBC driver that wraps around another one and
simply implement the PreparedStatement myself by using Strig concatenation.
This allows me to switch where I want without changing my code.
> > - Stability and correctness:
> > Think about a last name lookup HTML form and I type in
> > O'Connor
>
> ??
Think again ;-)
>
> > I also think PreparedStatements are cleaner code. Think about
> the parallel
> > with a method name and the arguments. You're not creating
> several methods
> > that do the same thing (apart from the arguments).
>
> I also agree . Specially if a query takes 10-15 parameters , I
> would prefer
> Prepared statement. However for executing very smal queries like
> "Select *"
> etc , I dont think it will give me any benefit.
> I am again saying that use of prepared statements should be done thought
> fully instead of considering it as "default" for executing the queries.
Now this is nice ??????
So you're avoiding PreparedStatements because they're slow, but you do issue
a select * ??????
You might start with replacing the * with the correct columns. It might give
you a better performance boost that the Statement.
at http://www.javaperformancetuning.com/tips/rawtips.shtml
about 5 articles are listed that state you should use 'PreparedStatement'
for performance.
Only 1 that - in a very particular case (DBMS and Driver) - shows the
opposite.
Geert Van Damme
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://archives.java.sun.com/jsp-interest.html
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.jsp
http://www.jguru.com/faq/index.jsp
http://www.jspinsider.com
