Hi Krishnan,
You make a valid point about the costs of creating a new transaction. For a good
Tx Mngr the act of creating a new transaciton may not be expensive. In Tyrex
(open source), for example, it's very cheap.
However, there are other expenses involved with managing multiple transactions
across a invocation chain. As the number of transactions increase the expense of
enlisting resources and synchronizing their work will impact performance. In
addition, multiple transactions require more effort by the resources in
isolating units-of-work. Compare this to a single transaction across an
invocation chain where all the resources are enlisted once, and execute
operations within the same tx context. New transactions are not free by any
stretch of the imagination.
Richard
Krishnan Subramanian wrote:
> 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".
--
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".
