Hey
Peter Michael wrote:
> 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.)
But then your interface could look something like:
public void doSomething(MyBean myCallBack)
i.e. no return values, but the bean could send results to MyBean through
the given callback.
Could you please outline how a method with your design would look like
and behave? Thanks.
> > > - 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.
I don't see why you need to change the spec to do this. It seems
possible to do this today without additions to EJB. What part in your
proposed EJB2.0 addition relies on the bean needing help from the
container?
>
> >
> > > - 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.
Do you really want the container to be able to interrupt the bean
whenever it feels like (because "best effort" would be the only likely
possibility)? I sure don't.
> 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.
I would imeplement the above with a stateless session bean. Why would
you want a singleton EJB to do this instead of a Stateless SB?
> > Sometimes it is not possible to get a list of instances.
>
> Why ?
It might be possible to test for existance through findByPrimaryKey, but
no complete "SELECT *" functionality is available in some cases. The
object might even be created upon findByPrimaryKey, so it's not there
until you ask for it.
> 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.
Use code generation. Of course you don't do this kind of stuff over and
over again. There's already a ton of stuff that I would want to automate
through code generation; this is just one more thing to generate.
If you want I can do this kind of tool (using my CodeGen tool, see
homepage, it would take about 30 minutes) and you can then use it "off
the shelf" ;-)
> 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!).
How would you declare which beans should be grouped? How would this be
implemented in an EJB server? Sometimes sending a message to a server is
not very interesting (servlets are often clients).
> 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.
I would probably simulate them with Stateless Session Beans in most
cases. Or use RMI objects.
> > 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.
But the problem is still that if you wait for exceptions or return
values it's not asynchronous. It's synchronous (by definition).
> > 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.
The requirements are definitely real-world, no argument there, but I
don't agree that your proposals make sense in the EJB spec. All of them
can easily be put on top.
The key question is whether any of your changes require the contract
between the container and the bean to be changed. I don't think it have
to do this for most of your suggestions.
/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".
