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