Thank you for your ideas, but ain't that all sime kind of strange? From my
point of view there is only one straightforward way: There has to be a
switch where I can tell the container that a specific ressource is accessed
only by JOnAS, so the programmer has not to do dirty tricks, and JOnAS can
keep cool about when to write back or read again data. The point is that
application servers - and so, EJB containers - tend to take place where
formerly database server's application technologies (stored procedures)
worked; and with this, they have to build up the synchronization point. With
the synchronization point moved from the DB tables to the Entity Beans in
the server, the server can work much more performant. So, I would suggest
two things:
a) We should try to convince the J2EE specs group to change the specs in a
way that there has to be a switch where one could tell that the
synchronization point is the EB and not the table.
b) We should include such a switch into JOnAS. A good place would be the
JOnAS-specific DD.
----- Original Message -----
From: "Halas, Miroslav" <[EMAIL PROTECTED]>
To: "'Markus Karg'" <[EMAIL PROTECTED]>; "Halas, Miroslav"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 5:50 PM
Subject: RE: how to tune jonas for performance problems
> There are two other I can think of,
> The first one is the yucky one you mentioned, to have two methods one with
> Required and with Supports attributes.
> The second solution is little different and indirect and maybe applicable
> only to our application. You basically do your own locking since you are
in
> stateless environment and your read methods take additional parameter if
to
> establish lock. The lock is established using transaction therefore it is
> guaranteed that no other method/client can establish lock after that and
> modify the data and therefore you can safely read even without
transaction.
> The each save methods which is always in the transaction is required to
> check for the lock and do not proceed if it doesn't own the lock.
>
> -----Original Message-----
> From: Markus Karg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 08, 2001 4:36 AM
> To: Halas, Miroslav
> Cc: [EMAIL PROTECTED]
> Subject: Re: how to tune jonas for performance problems
>
> 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".
