TopicSubscriber subscriber = session.createSubscriber(topic);
> connection.start();
> Message m = subscriber.receive(); // !!!
My main complaint with the synchronous operations oriented EJB technology
has to do with hung state robustness.
The EJB specs APIs that are 100% synchronous / blocking.
The new JMS integration is following the EJB API
philosophy of not supporting timeouts, or some other (any) means to detect
on the server side hung or too long APIs.
IMHO the DD parameter of timeout that gets applied to just transactional
method calls is not sufficient. For one, it applies to all transactional
method calls in this EJB, without regard to the DOM / usecase in effect and it
only
affects transactional methods...
I'd like the above subscriber.receive() to
be a non-blocking call. I could live with a blocking with given timeout
API. I would prefer a call back technology.
Are there any patterns that add robustness to a client getting hung in an
EJB non-transactional method. I.E. client stateless session bean calling
method doIt() on another stateless session bean. How can I protect the
first session bean from hanging, given that I can't create a timer
thread to timout the call to SB #2 ??
curt
--
Curt Smith
[EMAIL PROTECTED]
(w) 404-237-1166 x182
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
