Ah...I think I understand the difference that would lead you to prefer method level transaction control. I always have viewed the client of my transaction components as the use case controller. An interface would be exposed that provides a view into a component. In your example, my component would support transactions, since it's caller was dictating the use case. In order to provide finer grain protection (why I wish my interfaces dictated transaction support in MTS), I would have to layer my components and provide a use case layer. That would not be required if each interface could have separate transaction attributes. I see from your comment that by providing method level attributes, you could construct a facade that encapsulates your use cases. That is a different way of approaching the problem then I usually take (but an equally valid one).
Erik
--
Erik Huddleston, [EMAIL PROTECTED]
Chief Architect, eCustomers.com
Microsoft Java MVP
> -----Original Message-----
> From: Kevin Lewis [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 14, 1999 2:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Tx settings per method: necessary???
>
>
> Erik Huddleston wrote:
>
> > In COM(+): coclass == component. DLL's are simply a packaging
> > mechanism (like jars).
> >
> > This is an interesting discussion. How do people use method level
> > transaction attributes? It seems to me that transactional
> attributes
> > should be set at an interface (role) level. In other words, a
> > logically related set of operations should have the same transaction
> > attribute. I am wondering what sort of design wins you get with the
> > finer grain transaction control? (other than a slight performance
> > boost for methods that don't require transactions. In that case, I
> > would argue that interface inheritance would be the answer.)
>
> In the case of session beans, I see transactions as being a
> property of
> the system operation the method implements, as I usually see session
> beans (how I use them, at any rate) as application-level facades; some
> call these "use case controllers", or "application coordinators".
>
> In this view, session beans have behavior for a use case; some system
> operations are reads, others are writes. I see no reason to have
> transactions on the reads, and I would hate to have my writes
> separated
> from my reads.
>
> I find this model much cleaner than having to have a transactional
> property for the entire bean.
>
> As for entity beans, it's pretty much the same; some methods read,
> others write. Why have transactions on the reads?
>
> So I guess the question is, though one could in some cases set
> transactional properties at the bean level, and suffer little ill
> effect, why would you want to? Perhaps a different view of
> sessions and
> entities would lend itself to your view, but I don't understand your
> view, so I can't say.
>
> -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".
>
