>
> >
> > If I were to invoke a bean on methodB() on BeanB from threadA I would look up the
>home
> > object for BeanB, get the bean object and then invoke the method.
> > Context initialContext = new InitialContext();
> > BeanBHome beanBHome =
>(BeanBHome)narrow(initialContext.lookup(�java:comp/env/ejb/beanB�),
> > BeanBHome.class);
> > beanB = beanBHome.findByPrimaryKey(1);
> > beanB.methodB();
> >
> > This would start a new transaction.
> > What would be wrong with that?
>
> The naming context object may be aware of whether or not it is running within
> the server (or just in a client), and the lookup call could crash the server!
>
> > So the call to methodB does not occur in the same transaction context as the call
>to
> > methodA.
>
> The specification is written in such a way as to allow server/container
> vendors to attach arbitrary container-stuff as thread-local data in
> container-managed threads. Any attempt to use the server's EJB infrastructure
> from within a user-managed thread may result in the server attempting to locate
> the container-stuff for the invoking thread, even if that thread is acting only
> as a client to other beans. User-managed threads don't have any container-stuff,
> thereby it might not work.
So suppose from the main thread I create a new thread and do the above. (Get the
InitialContext, etc.). Such a thread doesn't have any container-stuff either. So how
does that
work?
dan
>
===========================================================================
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".
