Just a little note, we would probably want to do the share flag and cache
handling on a bean per bean instance, since some database tables can be
shared and some not at all even within one application.
Miro Halas
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 3:10 AM
To: [EMAIL PROTECTED]
Subject: Re-2: tuning jonas for performances
Philippe,
thank you for you response. I think we get this working. :-)
> I agree that some users want to access their database outside the
EJBServer.
> But I mean that today in JOnAS, we do not have fully tested this
> functionality,
> so we consider that it doesn't work. Among possible problems I can see:
> - the transaction isolation level should be TRANSACTION_SERIALIZABLE, and
> it's not
> always supported in all DB.
For this reason we need to have a property where the integrator or
administrator can set what TRANSACTION_LEVEL actually is used when JOnAS
wants to access a ressource that is SHARED=YES by a method that has
TX=REQUIRED or TX=REQUIRES_NEW.
> - when the user delete a raw in the DB, JOnAS don't see it and still has
> the
> object in its cache. OK, if we change policy, it will read the state and
> get
> an error, but if JOnAS try to create a new raw with the same key, it
will
> find it in the cache and return DuplicateKey Exception.
Policy has to be that if SHARED=TRUE JOnAS cannot use the cache; instead he
has to read from DBMS ALWAYS(!) since there could had happen an UPDATE or
DELETE or INSERT. It is not possible - from my point of view - to use a
cache in any way if SHARED=TRUE, but on the other hand, if SHARED=FALSE,
there is no need to read a row from the DB more than once. This means, the
shared flag is the ultimate determinant to decide wether to use a cache or
not. That's why we insist on that switch. If we do not have that switch,
caching would be a game of trial and error, what's quite errorprone,
instable and slow. If we have that switch, caching could be implemented to
ignore the database and only work directly and only with the cache; the DBMS
is need for writing a TX commit, and for reading ONCE only. Then, and only
then, the EJB server is the synchronization point of the whole system, and
this is, where J2EE is going to (to take over all jobs that a DBMS server
does at the moment). If we t!
hink this thought to th
in future there will be no more DBMS needed: For J2EE introduced Bean Query
Language, we "only" need to write a thin persistency layer that provides
stable memory. Then the last job of DBMS would be taken over, and the J2EE
server will do ALL what the DBMS did before. At that stage, legacy systems
could be switched off (and not before, since stable memory is not there
yet). Won't that be great? :-)
> OK, may be these are minor problems that could be fixed, but may be I have
> forgotten
> other cases that don't work properly. SO I think we have to spend a little
> time on this
> before telling we support this in JOnAS.
Ok, no hurry. I think we could wait to have this is the next major release
(2.4, 2.5?) of JOnAS, since it is a major change in JOnAS internal
structures.
> > 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.
> OK, we can introduce it anyway, it's the first step if we want to avoid
the
> read
> at beginning of each transaction.
Glad! :-)
> I see you agree with me that this is not an easy task to mix all policies
> in the container. But this seems to be the correct way to improve
> performances
> on entity beans. I just need some time to think about all this more
deeply.
Yes, now that I know that JOnAS was not made to have parallel access by
two-tier-clients, I agree with you...
> Thanks for your constructive remarks. I'll keep you informed when
> we decide to change JOnAS in this way.
Thank you
Markus
To: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
----
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".
