-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan,
Stefan Riegel wrote:
> - Request 1 running in Thread 1 gets a db connection.
> - Request 1 closes the db connection.
> - The JVM switches the running thread to Thread 2
> - Request 2 running in Thread 2 gets a db connection (the same db
> conn
Hi Stefan
you´re right, I wrote this with your first example in mind.
Regards
Flavio
Stefan Riegel gravou em 21/01/2009 01:36:34:
> Hello Flavio,
>
> thank You for your answer but isn't Your code the same as my code below?
> I don't see any significant difference.
>
> Regards
> Stefan
>
> Flav
> From: Stefan Riegel [mailto:stefan.rie...@telig.de]
> Subject: Re: Random Connection Closed Exceptions - Question
> to the code example
>
> So both code examples are correct, but the one in the
> docs minimizes resource usage?
Yes - but really only if there is additional pr
Thanks for the explanation. This makes things clearer. So both code
examples are correct, but the one in the docs minimizes resource usage?
All db related code I have written so far looked like this:
try {
// db related code with result set loops and more
// db related code done, first poss
> From: Stefan Riegel [mailto:stefan.rie...@telig.de]
> Subject: Re: Random Connection Closed Exceptions - Question
> to the code example
>
> Yes, I find the solution somewhat ugly and not very intuitive.
Which solution are you referring to? If it's the one in the Tomcat docs
Hello Flavio,
thank You for your answer but isn't Your code the same as my code below?
I don't see any significant difference.
Regards
Stefan
Flavio Crispim schrieb:
Hi Stefan
I would try this one:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if neede
Hello Alan,
unfortunately I'm not very experienced in "thread programming". But as I
understand does the proposed solution in the docs avoid the problem of
closing the connection object of the second thread. Yes, I find the
solution somewhat ugly and not very intuitive.
But the code below sh
Hi Stefan
I would try this one:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement("select ...");
ResultSet rs = stmt.executeQu
Hi Stefan
I went and read the comments more carefully and it seems to me that the
proposed solution is an attempt to avoid a race condition between
issuing the 'close' in
one thread and then it being closed again whilst its being used in
another thread.
If the problem is closing it twice th
Thanks Alan, just to make the thing really clear. You propose code like
this:
public void execute() {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Context envContext = null;
try {
Hi Stefan
You don't need to repeat the stmt.close();conn.close() etc in the 'try'
body. The 'finally' by definition is ALWAYS called and that is where you
should do the tidy up...
Alan Chaney
Stefan Riegel wrote:
I guess I understood the point with the "Random Connection Closed
Exceptions
I guess I understood the point with the "Random Connection Closed
Exceptions" Problem.
See at the end of
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
As I understand, only the connection itself must be protected this way.
The statement and ResultSet must not. I
12 matches
Mail list logo