Philippe,
thank you for that explanation. Sure it will be no easy decision how to
design it, but I am sure that it is possible in twenty lines and that twenty
lines will improve performance by 20 to 50 percent, so let's work on it.
There are lots of companies that are running legacy client-/server systems.
They still have the legacy clients feeding the database, while they are
writing EJB clients and run them in parallel. Why do you think that this
should be a problem? From the DBMS' view JOnAS seems to be a normal
two-tier-client that has more than one running transaction. This can only a
problem if JOnAS has incorrect transaction behaviour. Is that the case, we
should repair it. The DBMS-local transaction will prevent access problems,
since this ressource can be set to total isolation.
We need that switch ("This Ressource Is Shared") to let JOnAS know if a
ressource is accessed in parallel to JOnAS, e. g. by a two-tier-client.
If that switch is NO, so JOnAS has exclusive access, then we have to use
Option A: The container caches a ready instance between transactions and
does not re-read beans of that ressource at the begin of a transaction. We
then do not need to have total isolation on the DBMS-local transaction and
can reduce isolation level to a minimum, what bringt additional performance.
But if that switch is YES, so JOnAS has to deal with two-tier-clients
accessing the same bean of this ressource in parallel, we need to re-read
the bean of that ressource at the begin of a transaction since that
two-tier-client possibly has changed the ressource; also, we need to use
highest transaction isolation to prevent problems (phantom rows, dirty
reads and all that) on DBMS level. This is Option B. But we also need
another thing (what is a bit like Option C): A computer does not have
infinite RAM, so it may happen that we load and load and load beans and
cache them, but sometimes memory gets low. That means, for stability reasons
(and for speed, since full RAM means performance problems due to several
facts as fragmentation and so on), we need to have a switch to tell the
container not to load more than N instances into the cache (we must limit
the cache size). So when this level is reached, some instances get pooled
(they lose their data, what can be quite huge space if you think of fields
of String or Binary type; this should be the that instances, that's "last
change date" is eldest). We could let the admin tune this switch for
performance tasks,and we could make this switch bean-type dependent: max.
100 Employees, max. 10 Items, max. 50 Invoices and so on, for the admin
knows that the application will make spread access to the employess, but
uses only few items. I know this switch from Inprise Application Server and
it works well; but this will be a future option.
I think this sounds logical and easy to do. Sure we need to look at the
JOnAS specific details, but this will be manageable. I do not thinkt that
there should be ideas like to use special XA drivers or something, also I do
not think that it is a good idea to not use transaction to speed up
performance: This may work in one or the other special case, but in common,
what we need is what I wrote above.
More Ideas for future tuning: Inprise containers also have a switch for a
minimum value of instances per bean type. This is also good for performance,
since they get created and pooled at server boot and so the server has a
pool of N read to use beans. Also we could implement block fetching, what is
often used in two-tier-communication: If we need to load a bean, we could
also load the following N-1 beans (where N is the block size that is tunable
by a property per bean type) (every bean only gets loaded if not already in
the cache). The trick with this is, that this could be done by a background
thread, what means that JOnAS has ended loading the requested bean and
return thread control to the client, while the background task loads the
other beans. This is usable to do optimistic cache preloading, what leads to
an increadible performance thrust in applications, since cache is loaded
much faster than in the normal way. Sure, this are tasks that we can do once
we have solved the Option A/B problem; this are only tricks that make the
cache work better.
I wrote an data browser (looks like that windows explorer that shows a tree
leftside and a list rightside) to browse through our data. It uses a small
client side cache and a large server side cache. It runs fluently, even if
every access uses transaction required. The code for caching is about 50
lines, and I'm about to make it faster and shorter at the moment. For this
is only a proprietary, high-level cache, it shows where our server sided
caching could lead to. But clear is, that we really have to ensure that
there is the shared flag and that this flag works well, since there ARE
users accessing parallel to JOnAS, and J2EE is made for allowing that (to
access legacy databases).
Any comments welcome!
Markus
----- Original Message -----
From: "Philippe Durieux" <[EMAIL PROTECTED]>
To: "jonas-users" <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 4:56 PM
Subject: tuning jonas for performances
> Hi Markus, Miro, Christophe, and others
>
> First of all, thank you very much for your posts about
> jonas improvements. It was very interesting to read all this
> back from my vacations this morning.
>
> Let me precise what jonas does now, and what it could do later.
> Sorry if I don't reply at each of your mails, but they are a lot
> of them :-) I'll try to make a global answer.
>
> About clusters of EJBServers: No plan has been done to use
> JOnAS as cluster of EJBServers running the same entity bean.
> What is possible is to use many JOnAS servers using the same
> Transaction Manager, but a given EJB must run in only one of
> them. The JOnAS container has been designed with this assumption,
> and drastic changes should be necessary to take this into account. No flag
in the jonas specific
> deployent descriptor is
> needed thus, because we assume that the beans are always in the
> state "NOT SHARED". Indeed some jonas users have try to access
> the bean state on disk outside JOnAS and they always got problems.
>
> About JOnAS servers using a common Resource Manager: This is
> the same problem here. You should consider the Resource Manager
> as a part of JOnAS, so it is heavily bound to the jonas EJB
> container.
>
> About using local transactions instead of global ones:
> With most of the databases, you cannot modify data outside
> a transaction. This tx is said as local is it is local to this
> resource manager, it is said as global if it is known by JOnAS. This
transaction is said as
> distributed if it is known by the
> distributed transaction manager (JTM). THe transaction attributes
> will determine if a global transaction will be used or not.
> A distributed transaction will be used automatically since you
> use it on more than 1 JVM (EJBServer, or servlet/JSP, or client)
> In my opinion, JOnAS is responsible for starting transactions
> when needed, not the application. Note that if jonas decide to
> work in memory, obviously no transation will be used at all, but
> as soon as you access the database, you will use at least a local
> transaction.
>
> About not using transactions to improve perfs:
> It's true that if you do not use a transaction, your performances
> will be drastically improved, because you work in memory most
> of the time. The correct way to use transaction only when needed
> is to set transaction attributes as SUPPORTS for all "reading"
> operation, in the session bean and in the entity bean, and to
> set it to REQUIRED in all "writing" operations, also in both
> type of beans. So when for example, your session bean accesses
> an entity bean "reading" method, this one will be run inside
> a transaction or outside a transaction depending on the context,
> i.e. depending on the transaction attribute you have defined in
> the session bean method. I don't think that using 2 different
> XA drivers or demarking transations in client is the recommended
> way to process. See the Sun recommendations for more details.
>
> The current policy for managing entity instances:
> I should recall here the 3 policies described in the EJB spec:
> Option A: The container caches a ready instance between transactions. It
assumes that it has an
> exclusive access to
> the bean state, so it does not reload the bean state.
> Option B: The container caches a ready instance between transactions.
Since it does not assume it
> has exclusive access
> to the bean, it reloads the bean state at each transaction.
> Option C: The container does not caches a ready instance. It
> returns it to the pool after each transaction and must reload
> data at each tx start.
> Note that JOnAS uses today the option C.
>
> What could be done to improve this:
> Since in JOnAS the beans are considered as "not shared", i.e.
> the container has excluse access to the bean state, we could
> avoid reloading the bean state at each transaction. This would
> be the Option A. THis was not done because we have privileged
> the scalability instead of performance. It should be possible
> to mix both options: Keep the instance ready if possible but
> return it to the pool if to much instances have been created.
> This could be configurable (how ?). Anyway, I don't consider
> this as a trivial modif in jonas, even if the result is maybe
> 10 or 20 line changed somewhere. I know that this code is very
> sensitive and should be changed with care. Moreover, it is not
> clear for me when to choose to keep instance and when to choose
> to pool it. Many solutions are possible, but we need to choose
> one that seems simple and easy to understand for users.
> Every comment on all this is welcome!
> --
> 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".
