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