Markus Karg wrote:
> ...
> 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.
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.
- 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.
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.
>
> 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.
>
> 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 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.
> ...
Thanks for your constructive remarks. I'll keep you informed when
we decide to change JOnAS in this way.
--
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".
