Well, since client demarcated transaction is not what we want to do, this
would solve the problem, but is not very nice. You thought of other methods
to solve it. Is there one that omits client demarcated transactions?
----- Original Message -----
From: "Halas, Miroslav" <[EMAIL PROTECTED]>
To: "'Markus Karg'" <[EMAIL PROTECTED]>; "Halas, Miroslav"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 07, 2001 8:58 PM
Subject: RE: how to tune jonas for performance problems
> That is actually pretty simple. We have the same scenario as you described
> and there is many ways how to resolve it. One of them is for example have
> the read() method always just support transaction and then servlet which
> know based on parameter if the read is for read or edit can use user
> demarcated transaction to handle it.
>
> -----Original Message-----
> From: Markus Karg [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 07, 2001 1:38 PM
> To: Halas, Miroslav
> Cc: [EMAIL PROTECTED]
> Subject: Re: how to tune jonas for performance problems
>
> If I think about that, I think you are right and clients that are
accessing
> data for read only can avoid transactions to improve speed. But from the
> technical view I have some problems with doing that. We are using session
> beans that are accessing data over entity beans, since this is what the
J2EE
> blueprints wants one to do (and it's quite easy to do, too). For TX is
done
> by the container, and TX attributes are glued to the EB, how can we tell
> that if the EB's readXXX method is accessed from SB's method A it doesn't
> need a TX, while the same method needs a TX if it is accessed from the
SB's
> method B? Or do we have to code the EB's accessors twice, one time with
and
> one time without TX required in the DD?
>
>
> > In general you are right. But we have two distinct situations in which
> > clients are accessing date. In first it is solely for purpose of display
> and
> > in the second it is for purpose of editing. In the first one (and that's
> > most of it) we mainly care about speed of data delivery and display and
> > accuracy is less important (since in web environment, because you have
no
> > server side notification, somebody can modify the data anyway and you
will
> > be looking at old ones). In this case no transactions are required.
> > In the second situation when client expresses intent to modify the data,
> the
> > accuracy is more important than speed and we use transaction to read the
> > data and establish lock on them and then later store them and release
the
> > lock.
> >
> > Regards,
> >
> > Miro Halas
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 07, 2001 2:03 AM
> > To: Halas, Miroslav
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: how to tune jonas for performance problems
> >
> > Well, for me doing Two-Tier Client-Server Apps formerly, it is hard to
> > understand when to use a transaction and when not to - since you cannot
> > access a database via JDBC without a transaction, we EVER used one. So
> maybe
> > it would be good to have some cookbook when and when not to use a TX.
Some
> > years ago on university I learned to use a transaction whenever there
are
> > two clients accessing the same piece of information, and at least one of
> > them is a writing accessor. So for we running a client A, how can we
know
> if
> > client B is writing some time? That leads to the question: Don't we have
> to
> > use a TX EVER?
> >
> > ----- Original Message -----
> > From: "Halas, Miroslav" <[EMAIL PROTECTED]>
> > To: "'Philippe Durieux'" <[EMAIL PROTECTED]>; "Halas,
Miroslav"
> > <[EMAIL PROTECTED]>
> > Cc: "'Ilker Sozat'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
> > Sent: Friday, August 03, 2001 5:40 PM
> > Subject: RE: how to tune jonas for performance problems
> >
> >
> > > I agree with the mixed approach being inevitable to address both
> > performance
> > > and scalability. I'll keep this on my mind so once we get to the
> > performance
> > > optimization phase I can take a look at it. We have already modified
all
> > > read operations to be outside of transaction and it was about 100%
> > increase
> > > in performance. This would mainly affect the speed of updates, but it
> can
> > be
> > > significant as well since it is common situation in our approach that
> you
> > > read first and then you come back and update therefore the bean is
> already
> > > cached and can be reused. Thanks for the info,
> > >
> > > Miro Halas
> > >
> > > -----Original Message-----
> > > From: Philippe Durieux [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, August 03, 2001 2:17 AM
> > > To: Halas, Miroslav
> > > Cc: 'Ilker Sozat'; [EMAIL PROTECTED]
> > > Subject: Re: how to tune jonas for performance problems
> > >
> > > "Halas, Miroslav" wrote:
> > > >
> > > > I absolutely agree with you that at the end of each transaction the
> > beans
> > > > state has to be written to the database, no discussion about that.
> > > > I think what we were talking about is to bypass reloading of bean
> state
> > at
> > > > the START of transaction if the bean is already cached. I think you
> > should
> > > > be able to do that if you can guarantee that nobody else can modify
> the
> > > data
> > > > in the database without going through the entity bean. And if you
can
> > > > guarantee that, you can then set the flag in deployment descriptor
and
> > the
> > > > cached state of the bean will become reusable without reloading it
> from
> > > > database.
> > > > Do you think that is possible?
> > > >
> > > > Miro Halas
> > > Sure. This is possible. It's described in the EJB spec as "option A"
of
> > > commit policies. The drawback is that you do not have anymore a cache
of
> > > context/instances because you keep this context/instance ready for
use.
> > > In other policies (B or C) you can put these instances in a cache
after
> > > each transaction because you know that the bean state as bean written.
> > THis
> > > reduces the amount of memory used, in case of a big number of bean
> > > instances.
> > > This is necessary for the scalability of he jonas server.
> > > May be the best solution is to mix both policies :
> > > Keep when possible a ready state of the bean, but reuse it if needed
by
> > > another
> > > bean instance. This could work but lead to major modifications in
> > > jonas container.
> > >
> > > --
> > > Philippe Durieux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Bull - 1 rue de Provence - 38432 Echirolles Cedex France
> > > [EMAIL PROTECTED]
> > > -> Download our EJBServer at http://www.evidian.com/ejb <-
> > > ----
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > > include in the body of the message "unsubscribe jonas-users".
> > > 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 "unsubscribe jonas-users".
> > 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 "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
