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".
