> 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.
Yes, of course. You make an async call to an EJB. If the EJB does not return
anything, you are done. If the EJB need to return something, you specify an
return object in your async call to the EJB, which gets called by the EJB to
deliver return values. (Example: You have a call that take a long time. If
you
could send multiple returns, your client could display some results before
the
call is done as a whole.)
>
> > - 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.
If you have a long running call, you might want to cancel it, because of
user action or other circumstances. Or you might want to suspend a call
because you have another call, which has a higher priority, but you don't
want to loose the results of your first call, which already ran for half an
hour. Re-entrancy is not an issue if you have a thread for each instance of
the bean. Cancel could be supported by having the bean check a isCanceled()
(as in Thread.isInterrupted()) periodically.
>
> > - The caller should be able to wait for a return value and
> > optionally specify
> > a timeout.
>
> It can through transaction timeouts.
A lot of things *could* be done with the current spec in one way or another,
the point is that you want to do this in an easy, convenient and consistent
way.
With async calls I only would have to make an getReply( long timeout) and
not
have to fiddle around with transactions, especially when I don't need a
transaction
for my call.
>
> > 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.
You might have a Singleton EJB that you want to inform if you timeout, but
not if you are being removed. There is a subtle difference between timing
out and being removed.
>
> > 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?
See below.
> Sometimes it is not possible to get a list of instances.
Why ?
> 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.
This is exactly the thing I don't want to do. If you have a large-scale
component-based
application, developed by a large team and additional component from
third-party vendors,
you want to invent thing yourself. You want to use functionality off the
shelf! If you
have, say, 50 EJBs running in multiple containers on multiple computers, you
need a
mechanism to determine if something goes wrong. And you don't want to do
this in your
client-code over and over (maybe you have no only one, but several different
clients, some
only using part of the application, some using the whole app) and you don't
want to
do this in your bean code over and over.
>
> > 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?
Chaining statefull beans (as in the duke store) might not be a good idea as
someone
from the J2EE RI team admitted. There was a thread about
timeout objects on this list. The reason why I want to time
out multiple beans at the same time is simply consistency.
If one bean times out your app may be in an incosistent state.
Now if you had an error handler, it could send a message to your
client to inform it about this (Of course you could put this
code into each bean. Now that would be great idea!).
>
> > 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
I'm talking about Singletons not static EJBs! Quite a difference.
> 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?
Where in an application do you use Singletons? Configuration, state
management, error management. There are a lot uses for singleton.
Sometimes you can simulate them with entity beans, but if you have
multiple containers on multiple JVM you are pretty much out of luck.
>
> > 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.
>
No. I would call this function with TX_NOT_SUPPORTED.
> Suggestions are good, but IMHO you haven't quite thought through the
> consequences of your wishes. Please clarify where appropriate.
All these are real world requirement. They come from very large-scale
(== hundreds of thousands of lines of code+, 100+ people development
teams, multiple years of development) projects, real enterprise
applications. When people talk of J2EE, they seems to talk about
Java 2 eCommerce Edition (or Java 2 Internet Edition as someone
called it here). All I hear is online stores, online stores, online
stores (especially if you look at the website of application server
vendors). I'm not interested in online stores or eCommerce at all.
All the changes I proposed have been used for a long time or have
been recognized to make development and maintaining large-scale
applications easier. The point is not so much if you could do it with
the current spec, but how easy, convenient and consistent it is.
All your concerns are valid as long as you only want to build relativly
small applications like online-stores or information systems, which seems
to be the focus of J2EE right now. But once you start building larger
applications, the things I mentioned here really start to make sense.
Bye,
Michael
>
> 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".
>
===========================================================================
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".
