This is a common misconception with COM+. COM+ is not inherently stateless.
A COM+ object controls it's own lifetime by issueing a call to SetComplete()
or SetAbort() when it's finished with its state. SetComplete() is not
implicitely called at the end of each method call. Therefore COM+ objects
can be either stateful or stateless. It is true that transaction semantics
have to be defined at the coclass level (not method).
Hope this clarifies the situation.
-----Original Message-----
From: Cleveland Gibbon [mailto:[EMAIL PROTECTED]]
Sent: 13 October 1999 15:13
To: [EMAIL PROTECTED]
Subject: Re: Tx settings per method: necessary???
i'm not a COM+ guy but doesn't this have a lot to do with COM+ objects being
stateless. when you call a method on COM+ object, that object is activated
(created or fetched from the pool), run, and then deactivated (destroyed or
returned to the pool). In the EJB's more stateful model this restriction is
unworkable, but in the COM+ stateless model it's less of an issue. They
could have done it but probably spent more time doing other stuff...
cleve
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Lewis
> Sent: 13 October 1999 14:10
> To: [EMAIL PROTECTED]
> Subject: Re: Tx settings per method: necessary???
>
>
> Rickard �berg wrote:
>
> > Hey
> >
> > I think I'm going crazy. I'm currently looking into COM+, and it seems
> > you can only set transactional attributes on a per component basis. In
> > EJB you can set these on the method level.
> >
> > IMHO this is extremely limiting. So, I was wondering, does people use
> > the possibility to have different tx settings on different methods in
> > the same method, or do you only use them on a component level?
>
> I would agree that this would be limiting.
>
> We almost always have transactional and non transactional methods
> on a given
> session or entity bean. In sessions, writers are marked _required_, and
> readers are marked _supports_. In entities, writers get _mandatory_, and
> readers get _supports_.
>
> There may be a few cases where we just mark it at the bean level
> and leave it,
> but I can't think of any right now.
>
> -Kevin
>
> ==================================================================
> =========
> 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".
The statements and opinions expressed here are my own and may not represent those of
the company.
This e-mail is subject to copyright and the information in it is confidential. It is
intended only for the named recipient. You are advised not to disclose the contents of
this e-mail to another pers
on or take copies of it.
===========================================================================
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".
