Darlene Khosrowpour { SunEd } wrote:
> An EJB can talk to other Java objects which can then use JNI. These "helper"
>objects are
> not managed objects like EJBs are.
May I ask how an EJB obtains a reference to that kind of helper objects?
And how does it restore this reference between passivation and activation?
If it stores the reference in its persistent fields and the helper objects is
Serializable,
having the JNI code in the helper object or in the bean looks pretty much the same to
me. So,
if Sun has good reasons to discourage JNI code in a bean, Sun should also disapprove
the use of
JNI code in the closure of the bean.
Now, if the bean instantiates a JNI helper object at each activation and gets rid of
the
reference at the passivation, I guess it would be more in-line with what Sun suggests.
However, this would be inefficient as new helper objects get instantiated and garbage
collected
each time passivation/activation occurs. A pool of helper objects would have to be
designed to
preserve resources. But is this not what stateless session beans are for?
To say it plainly, I'm not much in favor of JNI restrictions on EJBeans. That looks a
bit too
extreme. It's ok for me if people disapprove it and suggest that I don't use it, but I
certainly hope that the containers will never reinforce this rule.
I'm also against the fact that an EJBean can not manage threads. What if I have a
particular
problem and I know of a solution that requires a parallel algorithm for efficiency?
Shouldn't I
be able to create threads and manage their lifetime for the duration of a remote
method call?
Regards,
Christophe.
===========================================================================
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".
