Richard,
you have to explain why mandating a particular TX attribute would help here.
you did agree that optmizations based on a particular TX attribute can be
done transparently in generated code at deployment time. It's quite a price
to pay to limit the bean developer and what do you gain? I can see valid use
cases of using other TX attributes with local interfaces that would be
disallowed that way. The local interface concept gives the bean developer a
lot of freedom (and responsibilty, of course) which I think is good, judging
based on experience from the projects I've been involved in.
I agree 100% with Jonathan as far as the assessment about CMP performance
problems being overrated is concerened. We've been working with fine grained
1.1 CMP for about 1 1/2 years in many projects and the main bottleneck
imposed by the spec we've seen is marshalling large structures over remote
interface boundaries. Anything else is really OK with a well-optimized
container (we're using Orion btw.).
Regards,
Robert
On Tuesday 08 May 2001 21:13, Richard Monson-Haefel wrote:
> Yes this is true. Good point. Also since Supports is not allowed (section
> 17.4.1) you would have to evaluate the tx context anyway, which would be
> achieved more easily if the EJBObject was generated. But the objective is
> to not to have to check for transactions and *most* importantly not to
> create a new transaction since that has a lot of overhead. This is one
> reason that Supports worked so well.
>
>
===========================================================================
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".
