Well the idea lost some steam when it was pointed out that local interfaces are
restricted to Mandatory, Required, and RequiresNew. If Supports were allowed it
would make sense since nothing has to be checked.
I think I've pointed out that the cost of starting a new transaction is
expensive and so using tx attributes that might force this operation should be
avoided. If tx Supports were mandatory there would not be an issue since the
bean would always propagate the existing tx context.
The point of the proposal for both transactions and security was to test the
idea that automatic and required propagation of the both the security and
transaction context would translate into higher performance of local interface
references in entity beans. I don't think anyone has shown that this proposal
wouldn't improve performance. I'm sure you would agree that avoiding new
transactions at local bean boundaries is cheaper and faster. The question is: Is
it worth the price of sacrificing the flexibility provided by different tx
attributes and security propagation? Perhaps not.
Robert Kr�ger wrote:
> 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".
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.jMiddleware.com
===========================================================================
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".
