Frank,
It depends on how you will access the RMI object. Recall
that RMI is just APIs. To use RMI in a distributed
system, it needs a protocol. As an example, if your EJB
server uses IIOP, and your RMI implementation uses IIOP,
then the transaction will be propagated from the EJB to
the RMI object, because IIOP supports transaction context
propagation (assuming there are no bugs or other limitations
in the IIOP implementation, which may not always be a good
assumption). Likewise, if your EJB and your RMI object
both use some other protocol which supports transaction
context propagation, the transaction will propagate. If your
EJB and your RMI object use different protocols, or use a
protocol that does not support context propagation (such as
JRMP, the default RMI protocol), then very likely the
transactional information will be lost when you cross VM
boundaries.
-jkw
Frank Sauer wrote:
>
> That makes sense. My mistake...
> I was under the impression that it got propagated through
> the bean's context, but that's just an access mechanism,
> not a propagation mechanism I understand now. Now as for
> Jeff's RMI comment in this thread.... How would that work?
> With the RMI object in a separate VM, the propagation through
> thread model doesn't hold, does it?
>
> Frank
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Tuesday, April 25, 2000 6:58 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Transaction context: Session Bean - non EJB -
> > Session Bean
> >
> >
> > Well I am not sure what the spec says, but in GemStone/J the
> > transaction
> > context is propagated with the thread and along any
> > distrubted component
> > invocations. So within a single JVM the transaction context propagates
> > through the thread. I would expect other servers to do similar?
> >
> > -Chris.
> >
> > > -----Original Message-----
> > > From: Frank Sauer [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, April 25, 2000 6:26 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Transaction context: Session Bean - non
> > EJB - Session
> > > Bean
> > >
> > > I'm not sure. How would the transaction context get propagated
> > > through the non-bean object to the second session bean?
> > >
> > > Frank
> > >
> > > > -----Original Message-----
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > > > Sent: Tuesday, April 25, 2000 1:29 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Transaction context: Session Bean - non EJB -
> > > > Session Bean
> > > >
> > > >
> > > > Sounds like a bug. Check with WL forums...
> > > >
> > > > -Chris.
> > > >
> > > > > -----Original Message-----
> > > > > From: Graham Parsons [SMTP:[EMAIL PROTECTED]]
> > > > > Sent: Tuesday, April 25, 2000 8:21 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Transaction context: Session Bean - non EJB -
> > > > Session Bean
> > > > >
> > > > > We have a Session Bean that calls a non-EJB Java class
> > > > which in turn calls
> > > > > another Session Bean.
> > > > >
> > > > > If we make both beans container managed transaction
> > > > demarcation, and the
> > > > > business method on the second bean have a "MANDATORY"
> > transaction
> > > > > requirement, we get a transaction does not exists error.
> > > > >
> > > > > However, I am told that if we make the first bean bean
> > > > managed transaction
> > > > > demarcation then all seems to work.
> > > > >
> > > > > The deployment environment is Weblogic 4.5.1.
> > > > >
> > > > > Any ideas ?
> > > > >
> > > > > Regards
> > > > >
> > > > > Graham
> > > > >
> > > > >
> > > > >
> > > > ==============================================================
> > > > ============
> > > > > =
> > > > > 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".
> > > >
> > >
> > >
> > ==============================================================
> > ============
> > > =
> > > 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".
> >
>
> ===========================================================================
> 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".
