https://issues.apache.org/bugzilla/show_bug.cgi?id=52066
Filip Hanik <fha...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Filip Hanik <fha...@apache.org> 2012-03-20 16:32:55 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
>
>
> Plus, it's not OK for the general user of the library to depend on your
> specific wrapper of InterruptedException into the SQLException. A user can
> switch to another implementation of connection pool and that particular
> library
> reporting policy may not be the same as this library's.
I am not sure I agree with this. The user has not invoked an "interruptable"
action, the user invoked DataSource.getConnection
http://docs.oracle.com/javase/6/docs/api/javax/sql/DataSource.html#getConnection()
This call says nothing about interruption nor does it declare it.
It is a totally different call than poll(...)
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html#poll%28long,%20java.util.concurrent.TimeUnit%29
>
> The right thing to do is to preserve the thread interruption status by calling
> Thread.currentThread( ).interrupt( ), and let the client code deal with it.
The reason an interrupt here would happen is cause we want to interrupt the
call to queue.poll, to the user, they need to be notified that their call will
fail using a SQLException.
>
> BTW, setting InterruptedException as a cause of SQLException is a GOOD THING,
> I
> don't want you to change that.
We do specify the root cause for troubleshooting reasons. If we don't clear the
flag, the thread can continue to run with a interrupted status, and I'm not
sure that is a good thing.
Feel free to reopen with a use case that may change the course of this
resolution.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
