>
> I did give an example (although it was very short). I quote myself:
> "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."
>
> Which is similar to what you did. If the invocation of the
> bean was done
> asynchronously (using a wrapper over JMS, or similar) it would produce
> the same result, and with no changes to the current spec.
I have thought of this myself, but I think this solution doesn't work with
the current spec. The current spec doesn't handle the case of delivering
JMS messages to an EJB. In fact the current spec is almost
totally silent about EJB and JMS. Thus you are counting on unspecified
behavior. According to the EJB spec 1.1 6.11.6 and 9.1.12 there may only
be a single thread in an ejb at a given time (with the exception of
reentrant
entity beans), so if the messaging service tries to deliver the message
while there is another call pending an exception will be thrown according to
the spec. And using an reentrant entity bean might not be a real alternative
(multiple threads inside a bean without synchronization?).
Even if this would work, there are differences to a real async call.
Remember the example with the messager and the crowd?
> Ok, fair enough. You could have a session bean that has a method:
> public void cancel(BeanPK pk);
> which sets a flag in a database that the EntityBean invocation of id
> "pk" has been cancelled. isCancelled() in this EntityBean can use then
> check the db and see whether it has been cancelled or not.
>
This would work, though I think it would not be a good solution. Every bean
method would need an additional parameter, a unique call id. Else it would
be possible that the wrong call gets canceled (if you are not carefull on
the client side). If you have many instances of 'cancelable' EJBs, that
would result in many database calls (guess that depends on the underlying
code and your database).
> > If you looked at the above code and read my previous posts,
> you would
> > have noticed that I propose that cancelling a call should
> the way you
> > interrupt a thread in Java, cooperative that is. That way your code
> > can determine, where and whether it is appropriate to cancel it (by
> > returning from the call).
>
> Ok, I understand. Much better then, that I can agree with.
> And it can be
> implemented as outlined above.
>
Having cancel() in the spec would still be an advantage because it would
be a well specified standard way to do this.
> > Good point. Still I also would like to be able to group my
> EBJs together
> > and assign error-handlers for things that you cannot catch with your
> > concept (like low-memory conditions, fatal errors,... ).
>
> I can catch this with my design; catch (Throwable) works pretty well.
If I have to embrace every method call in my EJB with a
try...catch(Throwable)
clause then something is clearly rotten in the state of denmark! Because
it means that the container doesn't provide good error handling mechanism.
So: put one into the spec!
> The APM takes care of many loose ends in this regard. Yes, I have
> considered starting such as FAQ (basically a compilation of
> the postings
> at E-I would be useful), but haven't found the time just yet.
After all it should be SUN's task to do this.
> Oh definitely, and I agree. The point is just what belongs in the EJB
> spec, and what should be put in other specs. Check the JSR list, there
> are a ton of related specs that cover many of your wishes.
Let me give you another example. Most of the suggstions you gave me remind
me of the following: There is a house with no doors, just windows. All
people have to enter the house through the windows. When I say: "Hey,
wouldn't
it be much more convenient to have a door?", you say: "Why, I think a window
is sufficient, this house really shouldn't have a door." Do you have doors
in Sweden? ;) For the requirements I have, EJB (1.1) is a house with no
doors.
BTW, which JSR do you mean? I think the only meaningful (to me) JSR are 19
(EJB 2.0) and 16 (J2EE Connectors). Neither one is public right now. 3 (JMX)
and 26 (UML/EJB Mapping) may be remotely interesting. But I don't see which
(apart from JSR-19) covers my wishes. Any help appreciated here.
> If someone made a asynch call library that worked on top of
> JMS and EJB,
> it would be portable and not any different from any other library you
> would use in your app. I would be surprised if any larger apps do not
> have any libraries included besides the raw beans.
>
> That said, I understand your point.
Of course you have some libraries in a large project, though the more
functionality you can buy off the shelf and the more you get from a single
product the better. So, please. Include those async calls in EJB 2.0.
Bye,
Michael
===========================================================================
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".
