It would be very unusual for a thread to switch away from a slow
operation it was blocked on without interrupting the operation,
and there would be no point in it to boot, because if you could
have the database op continue without a thread to receive the
result, you'd have a nightmare scenario of database threads being
blocked with their responses and hoping that a server thread would
pick them up, which would create locking chaos.
Your observation that thread id is consistent all but proves that
the thread waits on the db operation. :-)
That's from first principles as an author of other client/server
architectures, rather than an in-depth knowledge of jetty.
Bill
On 7/31/16 1:18 PM, Sunny Singh wrote:
Hello,
I am
using Jetty 9 and also using ThreadLocals. I was wondering
if one thread serving an HTTP Request could all of a sudden
become a carrier thread for another HTTP Request, in case
the first thread is waiting for some database
operation/another web service response. Also, when the
original HTTP request becomes active, I have seen the thread
ID didn't change, does this indicate that thread is the same
thread which started processing the HTTP Request?
Jetty Builds:
embeddedJetty
'org.eclipse.jetty:jetty-server:9.3.6.v20151106'
embeddedJetty
'org.eclipse.jetty:jetty-servlet:9.3.6.v20151106'
embeddedJetty
'org.eclipse.jetty:jetty-webapp:9.3.6.v20151106'
Thanks,
Sunny
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
