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