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