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