Richard,
A late entry into this discussion - but to comment
on your line:
"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".
In my personal opinion, I think you might have
over estimated the cost of starting a transaction.
Of course the reason might be an inefficient
implementation [by the vendor] of the JTS/JTA.
For example, with the Borland AppServer 4.5.1,
a trivial test I conducted with a session bean
being called by a client found that the performance
differences between the session's bean transaction
attribute set to "Required" to "Supports" was less
than 5% i.e. just a 5% degradation in performance.
Since most RPCs (to set up) execute usually in
the order of milliseconds - don't you think this
difference is extremely marginal?
And this was on the averages computed from
1000 RPCs i.e. each RPC causes a transaction
to be started (iff the T-attribute is "Required"/
"RequiresNew").
-krish
----- Original Message -----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 12:15 PM
Subject: Re: EJB 2.0: Local Interfaces and Transactions/Secrutiy
> 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".
>
>
===========================================================================
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".
