Journal Article - Asynchronous queries in J2EE

[Dirk Schreckmann]

In the March 2004 edition of the JavaRanch Journal, Kyle Brown has included a very nice article titled "Asynchronous queries in J2EE". Read up on how to "get [your] servlet to stop timing out on a really long database query."
Please post comments on the article in this thread.

[Dwight Coles]

The article mentioned a full set of example code could be downloaded,
but it made no reference of where to find that code.
Can we get the author to provide a URL link? Thanks!

Originally posted by Dirk Schreckmann:
In the March 2004 edition of the JavaRanch Journal, Kyle Brown has included a very nice article titled "Asynchronous queries in J2EE". Read up on how to "get [your] servlet to stop timing out on a really long database query."
Please post comments on the article in this thread.

[Tony Yan]

It is a well written article. I have one question about it since I am not too familar with MDB. It is nice to keep on polling the queue to see if the long query has finished for one request. But if there are 10, 100 or more users are doing the same long database query, and there will be equal number of requests lined up in the shared Message queue. In that case, I guess that performance will be really, really bad. So instead of being timed out on browser request, user can experience the data back 10, 100 times slower? Just a little confused on this. The author mentioned something like perfomance/scalability trade-off, is this about the same issue?
Thanks.

[Kyle Brown]

Originally posted by Tony Yan:
It is a well written article. I have one question about it since I am not too familar with MDB. It is nice to keep on polling the queue to see if the long query has finished for one request. But if there are 10, 100 or more users are doing the same long database query, and there will be equal number of requests lined up in the shared Message queue. In that case, I guess that performance will be really, really bad. So instead of being timed out on browser request, user can experience the data back 10, 100 times slower? Just a little confused on this. The author mentioned something like perfomance/scalability trade-off, is this about the same issue?
Thanks.

It doesn't quite work that way. The message queue is shared, yes, but since this solution uses message selectors to determine which message to pull from the queue, the number of messages on the queue doesn't have much of an effect on the time it takes each user to perform his query. Yes, if there are 100 simultaneous long queries going on it will take longer for each query due to database resource issues, but it's not due to the queue.
Kyle

[Kyle Brown]

Originally posted by Dwight Coles:
The article mentioned a full set of example code could be downloaded,
but it made no reference of where to find that code.
Can we get the author to provide a URL link? Thanks!

Well, if Dirk or one of the other friendly folks at the ranch can figure out where I can post the code here, I'd be glad to make it available.
Kyle

[shell Johnson]

Is the code available to download?

[Jesper Matthiesen]

I've implemented the case from "asynchronous queries in j2ee" and got it working in a WSAD 5.1 server test environment. To make it work, I had to do a "conn.start()" in the "checkForMessages" part of the code, for the receiver to ever get the message.

My main problem though, is that the messages
"An active transaction should be present while processing method allocateMCWrapper."
and
"An active transaction should be present while processing method initializeForUOW."
still show up, even when executing db calls within the MDB. I guess this means that my MDB is not taking part in a transaction!? I've tried to configure the "onMessage()" method of the MDB to require a transaction, but that doesnt make any difference.. any ideas?

btw, my db code uses UserTransaction, so that part of it should be ok, if the MDB is transacted, I guess...

[Anitha Krishnamurthi]

Hi Kyle,

It would be very grateful if you could mail the sample code to me. I am in urgent need of it.

my mail-id is [email protected]

Thanks in Advance,
Anitha