Hi!
Peter Michael wrote:
> Asynchronous calls:
> - It should be possible to call EJBs asynchronously. It should be
> possible to
> have one, multiple or no return values.
Could you outline what it would mean to make an asynchronous call, but
with return values? I can't see how that would work.
> - It should be possible to cancel pending calls (for beans that
> support this).
> - It should be possible to suspend/resume calls (for beans that
> support this), and
> a bean may even be able to do this itself (i.e. suspend itself and
> wake up when it
> gets a message from JMS).
Which problems would this solve?
How would this work in reality? It would seem that re-entrancy is
implied above.
> - The caller should be able to wait for a return value and
> optionally specify
> a timeout.
It can through transaction timeouts.
> ejbTimeout Function:
> - EJBs should have an ejbTimeout-Function that allows them to notify
> their client
> and maybe other EJBs of the timeout. ejbPassivate is not
> sufficient, because it
> is a big difference if a statefull session bean is swaped to disk
> or times out.
> The home interface should provide a getTimeout() function, so a
> client can
> determine when a approx. will time out.
Stateful SessionBeans will be ejbRemove'd when timed out. No need to
have the same on EntityBeans, and obviously not on Stateless
SessionBeans.
> Grouping of EJBs:
> - It should be possible to group EJBs within an application. For a
> given client,
> there should always be two standard groups: All EJBs in the
> current application and
> all EJBs created by this client. It should be possible for a bean
> to list all bean
> instances within its group and obtain references to them.
For what reasons? What is the rationale here?
Sometimes it is not possible to get a list of instances.
For beans where this is wanted it is easy to do this today by having
finders a la "findAll".
> Defined Error-Handling:
> - It should be possible to a install a default error handler for
> each group that pops
> in when a bean in this group has a fatal error or another
> specified condition
> (timeout, low memory condition,...) , so we can do some
> recovery/notification within
> the container.
You can do this today by layering your bean invocations with custom
functionality. Not very hard to do (some code generation only) and does
not require any changes to the spec.
> And/Or
>
> Concurrent Timeouts:
> - It should be possible to timeout multiple EJBs together, i.e. when
> one EJB times
> out, all other EJBs in this group timeout, too. (This could be
> handled by an error
> handler described above.)
If you have chained stateful sessionbeans you can remove beans down the
chain if you want. What scenarios do you want to cover?
> Singleton EJBs:
> - It should be possible to have singleton EJBs that are not only
> unique to an
> application running in a single container but unique to the whole
> application
> across multiple JVMs.
Considering that static variables are not durable this might not be a
good idea. Again: what problem do you want to solve? What is the
rationale for the introduction of this type of bean? What are its
characteristics?
> Before someone replies that asynchronous calls could be simulated/handled by
> JMS, I would
> like to say the following: To achieve the functionality I described above
> with JMS, we would
> have to do a lot of non-trivial coding. Why do I want async calls? Easy of
> use, performance,
> less coding. Just try to answer the following question: When I make a async
> call to an EJB
> that has crashed, I would get an exception.
No you wouldn't. Since the underlying implementation would most
certainly be transactionally aware an asynchronous invocation would only
be propagated to the bean if the transaction as a whole commits, so the
bean cannot throw any checked exceptions or return any return values.
The only thing you can know right away is whether the call could be
logged in the message queue.
Suggestions are good, but IMHO you haven't quite thought through the
consequences of your wishes. Please clarify where appropriate.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
