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".
