Hi Miro,
I actually like your idea of an additional cache. I was thinking
that the impact on the design would be big because I was thinking
that the pool would do the caching. But, if we split the 2 functions
it should be possible to add a cache on passivate/activate. As for
the finder methods, I am not sure but I think there is already some
caching done.
I suggest that we wait for Philippe Durieux to continue this
discussion, he is really the GUY for this.
Thanks,
Christophe
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Halas, Miroslav
>Sent: Thursday, August 09, 2001 7:20 PM
>To: 'Christophe Ney'; Halas, Miroslav; 'Markus Karg'
>Cc: [EMAIL PROTECTED]; 'Wayne Stidolph (E-mail)'
>Subject: RE: how to tune jonas for performance problems
>
>
>Hi Christophe,
>
>Thanks for the valuable information, more below,
>
>Miro Halas
>
>-----Original Message-----
>From: Christophe Ney [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 09, 2001 12:03 PM
>To: 'Halas, Miroslav'; 'Markus Karg'
>Cc: [EMAIL PROTECTED]; 'Wayne Stidolph (E-mail)'
>Subject: RE: how to tune jonas for performance problems
>
>Hi guys,
>
>Taking a little more time reading this again, here are a few additional
>comments.
>
>+ From what I understand, what JOnAS really does is to pool
>(anonymous)
>instances not cache them. Implementing an object cache is possible as
>Philippe D says but will have big impact on the container design.
>[Halas, Miroslav] Thanks for the info, it is important for me
>to know though
>that there is this opportunity because when we get to performance
>optimization phase any option will be good 8-)
>Why do you think it would have a big impact on container
>design? Excuse my
>naïve imagination in this case, but when an instance is
>returned to the pool
>at the end of operation or transaction it contains valid state
>commited to
>the database and it has also associated primary key. Wouldn't
>be just enough
>to modify findByPrimaryKey and other finders to check this cache if the
>object for given key doesn't already exist there before
>creating a new one
>and loading it with data (of course still assuming that the
>data source for
>this object, in jonas-XXX.xml woule be marked as NOT shared)
>
>+ Also , my main point I guess was that EJBs are designed to
>run in cluster
>of
>EJB servers and it seems to me that having the object cache in
>the container
>
>does not follow the same design. That is the reason why I was
>suggesting
>moving
>this to the resource manager.
>[Halas, Miroslav] This is the common scenario which everybody
>thinks about,
>but we have very strong case for deployment scenarios when the
>whole system
>will exists on single laptop or desktop machine and therefore
>we actually
>need container which takes as much advantage as possible from
>the fact that
>it is not being distributed.
>I was mentioning this, because I know that Weblogic had an
>optimization like
>this (the shared flag) since I believe 4.51
>
>+ For jonas EJB2 container, there is actually an on-going
>project (JORM)
>that
>aims at providing a (distributed) cache of persistent objects. This
>distributed
>cache will be connected to the container via connectors. (you may
>contact [EMAIL PROTECTED] for further information on
>this).
>[Halas, Miroslav] I have heard about this, but with my limited
>knowledge I
>am not sure how does it solves the problem of caching actual
>beans compared
>to just data, because from what I see the overhead connected with
>construction of beans and loading them with data is quite
>big.But I will be
>interested to look into this when it comes out.
>
>+ If the problem to solve is really displayed vs editable
>data. The approach
>I suggested using a non XA datasource might do the job. It
>requires using a
>non XA driver and a non XA pool such as the (StandardPoolDataSource)
>provided
>in jonas. If the XA drivers differs from the non XA one, the 2
>drivers must
>be
>loaded.As for "jConnect 5.", it should implement both XADataSource and
>ConnectionPoolDataSource.
>[Halas, Miroslav] Yes I agree with you that that's one way to
>do it, I was
>just wondering if there is a way how to take advantage of
>situation when
>user is periodically display and edit the same data object (in
>this case
>represented by EJB bean) by just reusing the same cached copy.
>
>[Halas, Miroslav]
>Anyway, thanks a lot for your insight, Miro Halas
>
>Thanks,
>Christophe
>Christophe Ney - mailto:[EMAIL PROTECTED]
>Enhydra Project - http://www.enhydra.org
>Lutris Technologies - http://www.lutris.com
>
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Halas, Miroslav
>>Sent: Thursday, August 09, 2001 5:21 PM
>>To: 'Markus Karg'; Christophe Ney; Halas, Miroslav
>>Cc: [EMAIL PROTECTED]; Wayne Stidolph (E-mail)
>>Subject: RE: how to tune jonas for performance problems
>>
>>
>>Christophe,
>>
>>I would agree with Marcus with my limited knowledge of EJB
>>server internals
>>that the problem of caching beans and distributed/local
>transaction are
>>independent. Seems like it is the EJB container who is
>>managing the bean
>>cache and therefore that would be the place to decide if the
>>bean can be
>>reused between transactions if the datasource is not shared.
>This would
>>eliminate the time needed to load the data from database
>>construct the bean
>>object for it. I think this is possible to implement even
>under EJB 1.1
>>spec.
>>
>>What you were describing is actually another level of
>>optimization how to
>>speed up transaction performance.
>>
>>Regards,
>>
>>Miro Halas
>>
>>-----Original Message-----
>>From: Markus Karg [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, August 09, 2001 4:51 AM
>>To: Christophe Ney; 'Halas, Miroslav'
>>Cc: [EMAIL PROTECTED]; Wayne Stidolph (E-mail)
>>Subject: Re: how to tune jonas for performance problems
>>
>>Christophe,
>>
>>thank you for jumping into this thread.
>>
>>I am not quite aware if you are right. I am not sure what part
>>of the system
>>you mean with "ressource manager", since I am not a profi in
>>EJb container
>>internals. If you mean a part of JOnAS that manages all
>>ressources, then I
>>think it is job of this service. It has to know - for every single
>>ressource - if this ressource is shared or not. If it is not
>>shared, there
>>is no need to re-read cached data at ever transaction's
>>beginning, since the
>>data cannot be changed. If it is shared, then JOnAS has to do what it
>>currently does: It has to re-read at every new transaction's
>>start, since
>>the data are likely to be changed. Is this what you mean with
>>"ressource
>>manager"? I do not think that it is job of the JDBC/XA driver,
>>since this is
>>not part of the JDBC spec, and since this would not work with
>>beans that are
>>using more than one ressource, where one ressource is shared,
>>but not the
>>other one.
>>
>>The other point is, that not every JDBC driver can be
>>configured to not use
>>TX (for I know). e. g. Sybase's "jConnect 5." XA-compliant
>>JDBC driver is
>>not able to do accesses without the boundaries of a
>>transaction (or what do
>>you mean with "using a different configuration"?).
>>
>>As I think over, the topic "non-shared datasources" and "using
>>local TX" are
>>completely independent. Think of a bean that uses BMP, and is
>>hold in two
>>different ressources (e.g. one table in a Oracle DB, one table
>>in a Sybase
>>DB). For safety (system crash etc.) there has to be a global
>>TX in addition
>>to the two local TX, independent of the case of beeing a
>>shared ressource or
>>not. If you would just switch off global TX and only use local
>>TX, the case
>>could happen that one server crashes down and reboots (the
>>local TX would
>>roll back then), while the other server has just committed -
>>the bean would
>>be in a undefined state. So you cannot mix up the topics of
>"non-shared
>>datasources" with "using local TX".
>>
>>What do you think?
>>
>>----- Original Message -----
>>From: "Christophe Ney" <[EMAIL PROTECTED]>
>>To: "'Halas, Miroslav'" <[EMAIL PROTECTED]>;
>"'Markus Karg'"
>><[EMAIL PROTECTED]>
>>Cc: <[EMAIL PROTECTED]>; "Wayne Stidolph (E-mail)"
>><[EMAIL PROTECTED]>
>>Sent: Thursday, August 09, 2001 10:21 AM
>>Subject: RE: how to tune jonas for performance problems
>>
>>
>>Hi guys,
>>Sorry for jumping in that late in this thread but I was out of
>>the office.
>>
>>In a), you suggest a flag for to specify the synchronisation
>point, but
>>isn't this supposed to be acheived by the resource manager.
>>For example,
>>I would suspect that one would use a different (configuration) of the
>>jdbc2-xa driver depending on weither the datasource is shared or not.
>>
>>This is at least my understanding of chapter 6.3 of EJB2
>>specifications:
>>
>>. If the deployment descriptor indicates that the local transaction
>>optimization is allowed, the
>>container may, but is not required to, use resource manager local
>>transactions instead of distrib-uted
>>transactions when executing the methods of the enterprise bean. If the
>>container chooses
>>to perform the optimization, the container must arrange that
>>the enterprise
>>bean and all beans
>>that it calls will share a single resource manager connection in a
>>transaction. The container col-laborates
>>with the resource adaptor (e.g., JDBC driver) to achieve the sharing.
>>
>>What do you think?
>>
>>Beside this, one trick that can help in some case where beans
>>are read-only
>>is to use a non XA pool. In this case, the TM transactions are
>>ignored by
>>the
>>datasource and the database connection is always in autocommit=true.
>>
>>Thanks,
>>Christophe
>>Christophe Ney - mailto:[EMAIL PROTECTED]
>>Enhydra Project - http://www.enhydra.org
>>Lutris Technologies - http://www.lutris.com
>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED]]On Behalf Of Halas, Miroslav
>>>Sent: Wednesday, August 08, 2001 9:37 PM
>>>To: 'Markus Karg'; Halas, Miroslav
>>>Cc: [EMAIL PROTECTED]
>>>Subject: RE: how to tune jonas for performance problems
>>>
>>>
>>>Your point b is the whole thing which has started this whole
>>>discussion and
>>>if I understood it correctly Philippe said that it is doable
>>>but the impact
>>>on Jonas code can be quite big.
>>>
>>>-----Original Message-----
>>>From: Markus Karg [mailto:[EMAIL PROTECTED]]
>>>Sent: Wednesday, August 08, 2001 2:24 PM
>>>To: Halas, Miroslav
>>>Cc: [EMAIL PROTECTED]
>>>Subject: Re: how to tune jonas for performance problems
>>>
>>>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".
>>>
>>
>>----
>>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".
