> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jubin Zawar
> Well, so far I don't understand why these features are not supported for
> message-driven beans :
>
> 1) dynamic selector for topic/queue which it listens to
The interest of dynamic selectors may be severely limited by the overhead
they impose. For example, imagine a selector based on time: the message
should only be delivered ten minutes after it's been received by JMS. This
means that JMS needs to constantly scan the queue of messages and reevaluate
the filter to determine new eligible recipients.
It's even worse for Topics, since JMS can no longer discard messages that
have been delivered: they need to be kept just in case some listeners with
dynamic selectors become eligible.
I don't believe such a dynamic selector will scale well.
What kind of dynamic query do you have in mind?
> 2) multiple selectors (yeah I know, if we want an MDB listen to several
> topics, why dont we just group these topics into one ? and yes, I
> can group 100 organisationally seperated topics in my application into
just one,
> holding thousands of messages - but then : what arguments are
> there against allowing multiple subscriptions ? and multiple changeable
subscriptions at
> runtime ??)
What is the difference between multiple selectors and selectors "AND'ed"
together?
> 3) dynamic definition of filters (is this already there ? I m not sure)
Not sure what you mean here.
> 4) some control about when messages should be delivered : a time range :
> let's say : "Deliver this message and trigger an MDB at least in 10
> seconds) - and here I might be fundamentally wrong and go against the
> container-managed-resource paradigm in EJB.
No, that's actually a useful feature, but I think it should be part of an
extension of its own, in order to avoid the problems I mentioned above.
> 6) concerning stateful session beans : I am missing one kind of bean in
> EJB - the "being" - I am not intending to have a bean run all the
> time. But at least what I want is to get its state back whenever I want.
It
> should be possible to specify a stateful session bean "mutant" which does
only get
> passivated, and not removed until a specified "range of time til
> eviction".
> For now, I have to resolve this by persisting the state of a stateful
> session bean every time into the database, to make sure it does not get
> evicted from the container. If the "being" is "reincarnated" 2 hours after
> the 1st calling client disappeared, I want its state back.
Just use a replicated stateful session bean (supported in Weblogic Server
6).
> 7) Schedules, Timers ! the whole EJB model is designed to be
> passive and to REACT rather than act. There always has to be a client
"kicking"
> the system to act. It is a big workaround to realise something like a
living
> component in there, which can wake up itself, bring itself to life, and
then do
> things, without the need for the kick of a client. At least EJB servers
> should provide one common mechanism for scheduled actions. This way one
> could implement a scheduler braught to life each second, and checking for
> which components in there should be woken up to ACTIVELY check for changed
> situations (the only thing changed might be the time since the
> last wakeup).
I believe you can address a fairly substantial part of this problem with
simple timers and Message-Driven Beans. Could you be more specific about
what you need?
--
Cedric
===========================================================================
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".
